On Aug 23, 2011, at 5:17 PM, Matt Foley wrote: > Dear all, > 0.20.204.0 will hopefully finish the release process soon, and it is time to > start talking about 205. As Owen mentioned, > I would like to volunteer as the Release Manager for 0.20.2xx, if that is > acceptable to the community. I would also like > to suggest some process changes. > > By continuing to provide sustaining releases of 0.20-security, the community > helps production users until later versions (v22 > and v23) reach stability. At the same time, we certainly do not wish > 0.20-security to be viewed as a "trunk"; it is important > that all patches go in trunk first, and only patches of manageable risk and > high value to production users, should go into > the sustaining releases. > > The goal of the following is to assure adequate community participation in > the release process, rather than just a bunch of > Jiras followed by last-minute debate in a Vote thread :-)
Note that the mechanism for encouraging community participation is very much in the hands of the RM. So, just do it. For example, the file you provided is much like the original STATUS file that I added to httpd development a long time ago, though I strongly suggest you commit it to subversion instead of expecting people to track it in email. For that matter, I thought Jira has the ability to track multiple releases already -- why not use the tracking system directly? I do feel a need to remind folks: releases are NOT a consensus decision, but the specific changes allowed within a given release can be vetoed with a valid technical reason that may be specific to that release branch (e.g., compatibility concerns are almost always scoped by version branch). You should be asking folks to make any negative opinions known as well, since that is critical to pruning the tree down to the set of patches that can actually be placed in front of the group to vote on as a release candidate. ....Roy
