on 1/30/01 11:10 AM, "Larry Isaacs" <[EMAIL PROTECTED]> wrote: > Hi Jon, > > I changed the release plan to not promise that all bugs will be > fixed as a requirement for release, since that isn't practical. > Some of the open issues were open prior to the Tomcat 3.2 release. > IMHO, if they weren't show stoppers for Tomcat 3.2, they shouldn't > automatically be upgraded to show stoppers for Tomcat 3.3. > > Is my assumption that the commitment to do maintenance will > apply in the release vote. This is only the vote on the plan, > and a +1 here is only committing to help with the plan. > > Deciding whether Tomcat 3.3 has outstanding bugs that should > prevent its release, IMHO, should also occur in the release > vote. It would be very appropriate to offer a specific unfixed > bug, or bugs, as a reason for a -1. Then those specific bugs > could be addressed. > > It is the release vote that is going to be the key one for Tomcat 3.3, > not this vote for the plan. If there are those who are, by their +1's > to the plan, willing to try to bring Tomcat 3.3 to a point where a > release vote can happen, then I think they should be able to try. > I don't think we should have to establish the outcome of the release > vote when trying to vote for the plan. > > Sound acceptable? > > Cheers, > Larry Larry, thanks for the excellent response. I think that I hear what you are saying. However, I still feel that it should be a goal of the release plan to attempt to specify which bugs will be closed before a release vote is made. That will solidify the ability to actually vote a -1 on the release if a particular bug is not fixed. In other words, I understand that you may not want to fix bugs that were open before 3.2 was released and were not closed after the release. How about this suggestion: Change the release plan to state: "All bugs that have been opened after the Tomcat 3.2.1 release will be closed before a 3.3 release is made." That would make me feel a lot more comfortable and would also set a nice precedent for not doing any more releases while we have bugs in an Open state. Note that you can still do a release with unresolved bugs...but someone should actually mark them as unresolved before a release. :-) thanks, -jon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
