The type of problems that cause teams to downgrade the quality of release have usually been "non-functional", such as
* Security issues * Packaging issues, either deployment related or legal (oops, forgot the license) We wouldn't want to downgrade the quality of a release because a new release obsoletes it. That's what the label "Best Available Release" is does :) But, we would want to downgrade the quality if there was a technical or legal reason why using it would cause problems for everyone, or at least a great number of users. Of course, hopefully, something like this will never, ever actually happen to us. :) -Ted. On 5/17/05, Clinton Begin <[EMAIL PROTECTED]> wrote: > > Thanks for all of the clarification Ted. I agree with all of them. I do > have one suggestion regarding this statement: > > >> if a problem is found with a distribution at any time, we should > >> "not hold our peace". We should immediately downgrade the > >> release and roll another that fixes the problem. ;) > > We should define the difference between "problem" and "bug" and possibly > clarify others like "new feature". > > We all have enough experience to know that it is by practical definition > that all software has bugs. All software also has a community that has an > interest in adding new features or performing compatibility testing with > other platforms (e.g. new VMs and new databases). > > So then, what is a "problem"? Certainly we can't simply downgrade the > release because it doesn't work on an untested database or contains a bug > that affects a new feature. > > Perhaps a "problem" by definition should be: > > A serious deficiency or error that impacts a formerly available > feature and breaks existing production code. > > So for example, the following are not problems that would warrant a release > rollback: > > * A bug or omission in a new feature (i.e. doesn't break existing code) > * A bug that is present because of a new or broken 3rd party driver, > database, virtual machine or operating system > * The failure to fix an existing bug reported in JIRA (whether attempted > or not) > * A bug that is fixed that DOES break existing code, but is agreed by the > community that it is the right way to go > * Production code is broken due to customization of the iBATIS framework > beyond the supported extensions > > Of course, these are all problems that would be fixed, but a new release > will not be downgraded unless it impacts existing production code. > > Does anyone agree? Disagree? > > Cheers, > Clinton > > On 5/17/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 5/16/05, Brandon Goodin <[EMAIL PROTECTED]> wrote: > > > +1 > > > > > > On 5/16/05, Clinton Begin <[EMAIL PROTECTED] > wrote: > > > > > > > > Vote now or forever hold your peace. > > > > :) I know we're having fun here :) ... but, for the record, if a > > problem is found with a distribution at any time, we should "not hold > > our peace". We should immediately downgrade the release and roll > > another that fixes the problem. ;) > > > > Unfortunately, I don't have a Java application in production against > > which to test the distribution, so I will have to abstain from the > > quality vote :( > > > > Do we have another PPMC member that has tested the distribution and > > can +1 it, so we have the minimum quorum of three? We could then pass > > the vote by the Incubator PMC and make this an official ASF release. > > > > And, just to nitpick, before the quality vote, we should try to use > > the word "distribution" or "milestone rather than "release". In the > > ASF lexicon, the word "release" implies that it's been approved by the > > project PMC and the community at large. Here, we've rolled an alpha > > distribution, that is on track for being an official release. > > > > -Ted. > > > > > > > > > > +1 > > > > > > > > Cheers, > > > > Clinton > > > > > > > > > > > -- HTH, Ted.
