I have problems with the Standard Release Criteria > Apply Patches section. There are well over 100 enhancements in bugzilla, some with patches. We shouldn't be forced to go through these before each release and examine the patches. We have to decide if the enhancement is good for Struts, then examine the patch, add the code sometimes in multiple places, and test it. As you know, this can take a long time and is a significant contribution by a committer. It takes far longer to apply a patch than it does to create one.
I think it's more appropriate to let committers examine enhancements when they get time and let them be committed or die in bugzilla as needed. Forcing us to examine every patch will slow releases and take some of the fun out of working on Struts. David --- Ted Husted <[EMAIL PROTECTED]> wrote: > I've posted a draft release plan. It's not linked but can be found here: > > http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html > > Since this is a transitional document, I'm not going to call for a vote > on it this morning, but will do so later, depending on how the comments > run. > > Points of note: > > * I set the roll-date for next Sunday, the 17th, which may be ambitious. > > If no one is burning to commit anything revolutionary right now, I'd be > more comfortable with rolling this on the 24th. > > * Initially, the distribution would be announced on struts-dev and not > posted to the public distribution directory. After voting on the Alpha > version, we would then post it publicly and announce to the other lists. > > The vote could also promote the distribution to Beta or GA, as the > Committers deem fit. > > * I've set this up as a boilerplate to outline what we need to do for an > > ongoing "point" release versus the initial "minor" release. In terms of > Bugzilla resolutions, the document suggests that we do for the initial > minor release (#.#.0) what we have always done. For any other point > release, we wouldn't require that every ticket be resolved, but would > still require that all showstoppers and tickets with patches be > resolved. > > * Since this would be the initial minor release for the 1.2.x series, > the "high bar" would apply. > > * I trimmed the containers to test against to Tomcat 3.3 and Tomcat 4.1, > > being the reigning References Implementations for our target platforms. > > * If anyone else wants to do the Release Manager thing for 1.2.0, feel > free to chime in -- I'm not jealous =:0) > > -Ted. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
