> From: Mike Kupfer <mike.kupfer at sun.com> ... > I've taken psarc-ext off of the cc list, since this seems off-topic for > the case. > > >>>>> "Roland" == Roland Mainz <roland.mainz at nrubsig.org> writes: > > Roland> Joseph Kowalski wrote: > > >> For projects to be integrated into the trunk, they should be as > >> perfect as possible. The catch phrase within the ON group of Solaris > >> is "FCS quality at all time". > > I think "perfect as possible" is an overstatement. "FCS quality all the > time" certainly allows for phased deliveries. And I would argue that > there is some room for putting back something in order to get feedback > and experience that we can't otherwise get or find a substitute for. > IMO opinion the criteria means this (no more and no less): anything we > integrate into the trunk, it should be something we're willing to ship > to customers.
Something we'd be willing to ship to our customers is what FCS quality means to me. We've been known to do EA's to get customer feedback. NSF V4 is I recall. Java SE is about to do one with Java DB. (Interestingly, it an EA because of a ugly set of feature dependencies and rather stiff Apache rules - the quality of Java DB is just fine!) Anyway, I probably mislead you by saying "perfect as possible". This would imply that you never putback. How about as "perfect as practical"? Some groups define this in terms of the number of P3 bugs. Others on the rate of incoming bug reports. Most do it by the seat-of-their-pants and if they have some experience, that usually works out surprizingly well. > Roland> I think it may be interesting to revisit the issue later (after > Roland> our putback is done) and look whether we can do any > Roland> optimisations... > > Yes, this would definitely be a good thing to do. I can already think > of one suggestion (don't wait until the code is "done" to have the ARC > review). "ARC early, ARC often." On a different topic, I feel for all of you outside the SWAN until we get our SCM story worked out. - jek3
