The "Code Freeze / Tag Date" is the date on which the CVS repository will be tagged with the B3 label, thus defining what is in the 1.1-b3 release. Obviously we want to get the bugs out, but I don't believe we can or should stop committers from making other positive changes to the code base if they so desire. This is open source - people scratch their itches.
We do not have a process in place where we define a code freeze date, then a verification period, then the release. The code freeze date essentially defines the release, unless the release manager (or anyone else) finds a showstopper after the code is tagged but before the release is announced. That's the way it has always worked before, and in other Jakarta projects I've been involved with. I'd like to make the observation that the release plan I posted is, with the exception of the specific bugs listed, almost iidentical to those for 1.1-b1 and 1.1-b2. The process itself is identical. However, if what you're suggesting is that we need to discuss a new release process, then I guess we'd better hop to it! ;-) -- Martin Cooper On Thu, 12 Dec 2002, Robert Leland wrote: > > I have checked in a proposed release plan, which is available for > > review on the Struts web site: > > http://jakarta.apache.org/struts/proposals/release-plan-1.1b3.html > > Release plans must pass by a majority vote of committers on the project, > > I am > -1 with the --current-- proposal, > > REASON > +1 if we can agree on some form of the following : > > I would really like to get this release out ! > I propose that we explicitly spell out what > a Code Freeze means to keep us/me focused on fixing only bugs. > > Code Freeze / Tag Date - Saturday, December 14, 2002 > If we can agree Code/Document Freeze to include: > > I expect these are a no brainier: > A) No Improvements/Enhancements to code, > So we can concentrate on items that are not > working correctly. > B) No New features, > It's too easy to make a small enhancement that > reverberates through the code. > C) Code Reformatting, including imports optimization, > unless a bug was fixed also. > (Lately I am guilty of this one !) > > I would also like to hold the documents to the same standards > > D) No Document reformatting, breaking up pages etc. > Ok to: Clarifying existing docs, Adding missing Docs, > fixing JavaDoc is Ok. > > Example: An acceptable change would be to document Tokens. > I have been meaning to do for 22 months now ! > I would rather we spend time concentrating on existing content. > E) No new references to resources, books, > announcements, tools etc... > Again spending available time concentrating on > existing content that is incorrect or unclear. > > > > > -Rob > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
