You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Benjamin Reed <br...@yahoo-inc.com> on 2011/01/26 19:27:34 UTC
pushing the 3.3.3 bugs
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
Re: pushing the 3.3.3 bugs
Posted by Patrick Hunt <ph...@apache.org>.
On Wed, Jan 26, 2011 at 10:27 AM, Benjamin Reed <br...@yahoo-inc.com> 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.
>
Any non-blocker jiras are always pushed to the next release if they
are not resolved for the current release. What you are describing is
how we always do things. Blockers always hold up the release unless
specifically addressed otherwise (changing the severity or agreeing to
push it to a subsequent release).
> 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.
>
That sounds fine. However we always maintain a fix branch in parallel
in case something critical (blocker) comes up before the trunk is
ready.
> 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.
In theory that's how it should work. However the trunk release has
gotten stalled.
One way to un-stall things is for someone to step up and agree to be
release manager for 3.3.3 and 3.4.0 releases (doesn't have to be the
same person). That person is responsible for determining when the
release is ready, what's in the release, etc...
Patrick
Re: pushing the 3.3.3 bugs
Posted by Patrick Hunt <ph...@apache.org>.
On Wed, Jan 26, 2011 at 12:39 PM, Benjamin Reed <br...@yahoo-inc.com> wrote:
> 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.
>
We wouldn't have to adopt everything, just the bits we like.
re 3.4.0 vs 3.4.1, a RM is responsible for a single release. It would
be up to that person to sign up for a subsequent release, or not.
Someone else would have to pickup the ball in that case. Another good
reason for having more committers.
> 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.
This is what you were referring to in your follow-up email on this
thread, right? What you are saying here is what the RM would have to
do. Pull patches from trunk to include in the fix release. In some
cases though the RM would be on the hook to get the patch backported
(or do the work themselves). Hopefully this person would work closely
with the community to capture the patches they are interested in, but
eod it's up to the RM what they will include. Of course the PMC could
then reject the release .... etc...
Patrick
>
> 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<fp...@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
>>>>>
>>>>> fpj@yahoo-inc.com
>>>>> direct +34 93-183-8828
>>>>>
>>>>> avinguda diagonal 177, 8th floor, barcelona, 08018, es
>>>>> phone (408) 349 3300 fax (408) 349 3301
>>>>>
>>>>>
>>>>>
>
>
Re: pushing the 3.3.3 bugs
Posted by Benjamin Reed <br...@yahoo-inc.com>.
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<fp...@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
>>>>
>>>> fpj@yahoo-inc.com
>>>> direct +34 93-183-8828
>>>>
>>>> avinguda diagonal 177, 8th floor, barcelona, 08018, es
>>>> phone (408) 349 3300 fax (408) 349 3301
>>>>
>>>>
>>>>
Re: pushing the 3.3.3 bugs
Posted by Patrick Hunt <ph...@apache.org>.
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 <fp...@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
>>>
>>> fpj@yahoo-inc.com
>>> direct +34 93-183-8828
>>>
>>> avinguda diagonal 177, 8th floor, barcelona, 08018, es
>>> phone (408) 349 3300 fax (408) 349 3301
>>>
>>>
>>>
>>
>
Re: pushing the 3.3.3 bugs
Posted by Patrick Hunt <ph...@apache.org>.
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 <fp...@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
>>
>> fpj@yahoo-inc.com
>> direct +34 93-183-8828
>>
>> avinguda diagonal 177, 8th floor, barcelona, 08018, es
>> phone (408) 349 3300 fax (408) 349 3301
>>
>>
>>
>
Re: pushing the 3.3.3 bugs
Posted by Benjamin Reed <br...@yahoo-inc.com>.
sorry, i read your messages backwards. i like your idea.
ben
On 01/26/2011 11:15 AM, Patrick Hunt wrote:
> On Wed, Jan 26, 2011 at 10:38 AM, Flavio Junqueira<fp...@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
>>
>> fpj@yahoo-inc.com
>> direct +34 93-183-8828
>>
>> avinguda diagonal 177, 8th floor, barcelona, 08018, es
>> phone (408) 349 3300 fax (408) 349 3301
>>
>>
>>
Re: pushing the 3.3.3 bugs
Posted by Patrick Hunt <ph...@apache.org>.
On Wed, Jan 26, 2011 at 10:38 AM, Flavio Junqueira <fp...@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
>
> fpj@yahoo-inc.com
> direct +34 93-183-8828
>
> avinguda diagonal 177, 8th floor, barcelona, 08018, es
> phone (408) 349 3300 fax (408) 349 3301
>
>
>
Re: pushing the 3.3.3 bugs
Posted by Flavio Junqueira <fp...@yahoo-inc.com>.
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
-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
fpj@yahoo-inc.com
direct +34 93-183-8828
avinguda diagonal 177, 8th floor, barcelona, 08018, es
phone (408) 349 3300 fax (408) 349 3301