One other thing to keep in mind with this model. The RM is responsible for backporting (or working with the author to backport) any issues that go into a fix release. Today we require authors to provide patches for both the fix branch and the trunk (for fixes). If changes are committed to the trunk, and at some point a RM steps up to create a fix release, those changes need to be applied to the fix branch. Granted, this seems to fit well with Ben's original suggestion of limiting the number of fixes that go into fix releases. It's a step away from what our users have come to expect though - that we essentially maintain a fix release branch with most/all fixes, as well as a new feature development branch (trunk).
Patrick On Wed, Jan 26, 2011 at 11:15 AM, Patrick Hunt <ph...@apache.org> wrote: > > On Wed, Jan 26, 2011 at 10:38 AM, Flavio Junqueira <f...@yahoo-inc.com>wrote: > >> Ben, Your proposal in general sounds reasonable to me with the exception >> of "do a release from just a branch if it is something that pops up quickly >> right after a >> release". I don't see a reason for binding it to time, and instead we >> could say that we will have a branch release if: >> >> 1- there is an important bug fix that needs to be released >> 2- we are not close to a trunk release >> > > One problem with our current model is that we create a release placeholder > before we have a release manager for the release. What you are suggesting > makes sense to me, but it introduces another problem. > > Today we create release placeholders as soon as we push out a release, we > always have placeholders for the upcoming fix/trunk based releases. This > gives us a place to hang JIRA issues off of, it allows us to triage new > issues and slate them for a particular release. > > We could instead go to the model of having only trunk, no placeholder at > all for the fix and next major/minor release (3.3.3/3.4.0 today). Then, at > some point, a release manager could step up and volunteer to do a release, > say 3.3.3, they would then be responsible for determining what's in the > release. They would work with the community to do this, in the end they (the > RM) are the arbiter for what's in/out of the release. > > We could try this and see how it works. It would allow for what Ben is > suggesting. > > EOD though it requires someone to step up and take on the responsibility of > being the RM. (hint hint :-) ) > > Patrick > > >> >> -Flavio >> >> >> On Jan 26, 2011, at 7:27 PM, Benjamin Reed wrote: >> >> i would really like to get 3.3.3 out because of the fixes that just went >> in. >> >> there are quite a few bugs that are marked for 3.3.3, but i think they >> can all be pushed to 3.4.0. >> >> i would really like to push everything to 3.4.0 and then work on getting >> the 3.4.0 release out. we haven't done a release from trunk in a while, >> but that is the only code that gets tested by hadoopqa. i think it is a >> bad idea to be releasing from branches that are not regularly tested. >> >> going forward doesn't it seem like a better idea to only do a release >> from just a branch if it is something that pops up quickly right after a >> release. otherwise, we should be releasing from trunk and possibly doing >> a simultaneous release from a branch. >> >> ben >> >> >> *flavio* >> *junqueira* >> >> research scientist >> >> f...@yahoo-inc.com >> direct +34 93-183-8828 >> >> avinguda diagonal 177, 8th floor, barcelona, 08018, es >> phone (408) 349 3300 fax (408) 349 3301 >> >> >> >
