On 5/29/2010 11:58 PM, Paul Harper wrote:
Whatever happened to 'Release early and release often'?
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html
2010.?? will be full of preventable bugs because users will not have been
giving feedback to the developers.
Yeah, and the 'release early, release often' method has worked soooo
well for other free softwares' quality (*cough* Fedora *cough* Ubuntu
*cough* Gnome).
Essentially what's going on for the RC is that there has been a
determination *which* bugs are critical to get fixed, and the fix
process is limited to those bugs, and extensive QA runs are being done
on the whole thing - QA that is too intensive to be done on "normal"
development builds. So, the list of "bugs-to-be-fixed" is pre-defined
at the start of the RC process, and only those bugs found out in the QA
test cycle *might* also get fixed. User-reported bugs from RC betas
wouldn't get fixed in any case, so why bother producing them? Its just a
distraction for developers.
ESR's theory works best on software where there aren't already extensive
test harnesses, *and* when the amount of work required to diagnose and
fix user-reported bugs won't impact schedules. That is, the C&B method
works best with software that doesn't have a tight, fixed schedule.
People forget that bugs take time to diagnose and make a determination
of their importance, time which may not be available in a fixed schedule
project.
OpenSolaris adheres to the B of C&B during normal development build
cycle (why else release intermediary builds except to have it tested by
outsiders?). For RC work, the Bazaar method is much less useful (and,
can be detrimental to schedules), so it's better to keep the RC work
strictly inside the developer community, and exclude the user community
for the short period of time it takes to produce a Release.
All that said, I'm still a little mystified as to why the "normal"
development builds are being held back.
(and, note: I'm not 100% sure that the RC process is the above. What I
describe is how we do it in the JDK, and I'm making some (probably
accurate) extrapolations to the Solaris group.)
And, of course, I don't speak for Oracle in any way, and have no
non-public knowledge specific to the Solaris group's work.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org