this is an interesting read. i'm not a big fan of the even odd numbering
scheme. i'm also unclear how it work. for example, lets say i signed up
to be the RM for 3.4.0. i branch, stabilize the code, and then do a
release. would i also be in charge of 3.4.1? i would hope the answer
would be yes. i think the RM should have some long term commitment until
they decide to retire the 3.4 series.
it would allow things to flow a bit better if the RM pulled patches from
trunk rather than contributors having to work with two versions of code
to do a patch. of course that puts more work on the RM.
ben
On 01/26/2011 11:30 AM, Patrick Hunt wrote:
FYI, this is a _really_ good read, perhaps we should try something like
this, at the very least we should document our approach:
http://httpd.apache.org/dev/release.html
<http://httpd.apache.org/dev/release.html>Patrick
On Wed, Jan 26, 2011 at 11:23 AM, Patrick Hunt<ph...@apache.org> wrote:
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
