Committing bug and test fixes to branches

[lars hofhansl <la...@apache.org>]

We currently have 4 branches (0.94, 0.96, 0.98, and trunk).
For bug and test fixes, do we really need the release managers to agree to every single check-in.
Andy
 currently wants to stabilize the tests in 0.98 so looking at every 
change there makes sense and was specifically requested by him.

What about 0.94, 0.96, and trunk. I do not feel like I need to be pinged for every bug/test fix for 0.94.

I
 would propose that committers use good judgment and commit small 
changes to fix bugs and tests to any branch without a nod from the RMs, unless specifically request as with 0.98. If we can't trust a committer with that, (s)he should not be a committer.
For larger fixes and any new feature the RMs should be pinged of course.


Related to this, it seems we're a little loose with trunk as in "It's OK it's just trunk". Trunk will become a release eventually and IMHO we should aim for keeping trunk in a releasable state as much as this is possible.
If we had done that before 0.96, Stack would not have had to face the superhuman task of getting 0.96 back to a releasable state.

Does trunk need a release manager?


Comments?

-- Lars

Re: Committing bug and test fixes to branches

[Ted Yu <yu...@gmail.com>]

bq. The trunk RM, would basically just monitor the tests

I think every committer should watch out for reproducible test / build
failure after checkin. This way the maintenance of trunk releasable state
would be easier to achieve.

Cheers


On Fri, Jan 3, 2014 at 8:56 PM, lars hofhansl <la...@apache.org> wrote:

> I think features and changes that can reasonably be committed in one go
> are fine to go into trunk directly.
>
> For large features (where temporary changes have to stashed somewhere and
> folks want to collaborate while the feature is implemented) a branch seems
> best.
>
> That might in fact be a good rule of thumb: No commit of 1/2 finished
> features that cannot be broken down into smaller chunks that are useful by
> themselves...?
>
> The trunk RM, would basically just monitor the tests and make sure we're
> not gliding into non-releasable state.
>
> -- Lars
>
>
> ----- Original Message -----
> From: Ted Yu <yu...@gmail.com>
> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> Cc:
> Sent: Friday, January 3, 2014 5:41 PM
> Subject: Re: Committing bug and test fixes to branches
>
> bq. getting large features or even moderately sized features into branches
> off of trunk
>
> +1
> We should embrace the above model.
>
> bq. There are a handful these being worked on
>
> I want to mention the unification of mvcc and sequence Id as one more such
> feature.
>
> Cheers
>
>
>
> On Fri, Jan 3, 2014 at 5:32 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
> > I think I like the idea of a release manger for trunk but is seems like a
> > potentially all-consuming task requiring superhuman vigilance.
> >
> > Would working more on feature branches with invested
> > devs/commiters/shepards is another way of potentially achieving the goal
> of
> > a releasable trunk?  This could be instead of or in conjunction with the
> > trunk RM idea.
> >
> > Trunk would theoretically only get completed features, refactors, or bug
> > fixes and would remain releasable.
> >
> > I've been espousing getting large features or even moderately sized
> > features into branches off of trunk. There are a handful these being
> worked
> > on or recently proposed (new master, multi-wal, local 2ndary idx, shadow
> > regions, read replicas, and the visibility tags stuff).Keeping these in
> > branches reduces the chance that trunk gets into a state with half done
> > feature.
> >
> > Jon
> >
> >
> > On Fri, Jan 3, 2014 at 3:09 PM, lars hofhansl <la...@apache.org> wrote:
> >
> > > We currently have 4 branches (0.94, 0.96, 0.98, and trunk).
> > > For bug and test fixes, do we really need the release managers to agree
> > to
> > > every single check-in.
> > > Andy
> > >  currently wants to stabilize the tests in 0.98 so looking at every
> > > change there makes sense and was specifically requested by him.
> > >
> > > What about 0.94, 0.96, and trunk. I do not feel like I need to be
> pinged
> > > for every bug/test fix for 0.94.
> > >
> > > I
> > >  would propose that committers use good judgment and commit small
> > > changes to fix bugs and tests to any branch without a nod from the RMs,
> > > unless specifically request as with 0.98. If we can't trust a committer
> > > with that, (s)he should not be a committer.
> > > For larger fixes and any new feature the RMs should be pinged of
> course.
> > >
> > >
> > > Related to this, it seems we're a little loose with trunk as in "It's
> OK
> > > it's just trunk". Trunk will become a release eventually and IMHO we
> > should
> > > aim for keeping trunk in a releasable state as much as this is
> possible.
> > > If we had done that before 0.96, Stack would not have had to face the
> > > superhuman task of getting 0.96 back to a releasable state.
> > >
> > > Does trunk need a release manager?
> > >
> > >
> > > Comments?
> > >
> > > -- Lars
> > >
> >
> >
> >
> > --
> > // Jonathan Hsieh (shay)
> > // Software Engineer, Cloudera
> > // jon@cloudera.com
> >
>
>

Re: Committing bug and test fixes to branches

[lars hofhansl <la...@apache.org>]

I think features and changes that can reasonably be committed in one go are fine to go into trunk directly.

For large features (where temporary changes have to stashed somewhere and folks want to collaborate while the feature is implemented) a branch seems best.

That might in fact be a good rule of thumb: No commit of 1/2 finished features that cannot be broken down into smaller chunks that are useful by themselves...?

The trunk RM, would basically just monitor the tests and make sure we're not gliding into non-releasable state.

-- Lars


----- Original Message -----
From: Ted Yu <yu...@gmail.com>
To: "dev@hbase.apache.org" <de...@hbase.apache.org>
Cc: 
Sent: Friday, January 3, 2014 5:41 PM
Subject: Re: Committing bug and test fixes to branches

bq. getting large features or even moderately sized features into branches
off of trunk

+1
We should embrace the above model.

bq. There are a handful these being worked on

I want to mention the unification of mvcc and sequence Id as one more such
feature.

Cheers



On Fri, Jan 3, 2014 at 5:32 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:

> I think I like the idea of a release manger for trunk but is seems like a
> potentially all-consuming task requiring superhuman vigilance.
>
> Would working more on feature branches with invested
> devs/commiters/shepards is another way of potentially achieving the goal of
> a releasable trunk?  This could be instead of or in conjunction with the
> trunk RM idea.
>
> Trunk would theoretically only get completed features, refactors, or bug
> fixes and would remain releasable.
>
> I've been espousing getting large features or even moderately sized
> features into branches off of trunk. There are a handful these being worked
> on or recently proposed (new master, multi-wal, local 2ndary idx, shadow
> regions, read replicas, and the visibility tags stuff).Keeping these in
> branches reduces the chance that trunk gets into a state with half done
> feature.
>
> Jon
>
>
> On Fri, Jan 3, 2014 at 3:09 PM, lars hofhansl <la...@apache.org> wrote:
>
> > We currently have 4 branches (0.94, 0.96, 0.98, and trunk).
> > For bug and test fixes, do we really need the release managers to agree
> to
> > every single check-in.
> > Andy
> >  currently wants to stabilize the tests in 0.98 so looking at every
> > change there makes sense and was specifically requested by him.
> >
> > What about 0.94, 0.96, and trunk. I do not feel like I need to be pinged
> > for every bug/test fix for 0.94.
> >
> > I
> >  would propose that committers use good judgment and commit small
> > changes to fix bugs and tests to any branch without a nod from the RMs,
> > unless specifically request as with 0.98. If we can't trust a committer
> > with that, (s)he should not be a committer.
> > For larger fixes and any new feature the RMs should be pinged of course.
> >
> >
> > Related to this, it seems we're a little loose with trunk as in "It's OK
> > it's just trunk". Trunk will become a release eventually and IMHO we
> should
> > aim for keeping trunk in a releasable state as much as this is possible.
> > If we had done that before 0.96, Stack would not have had to face the
> > superhuman task of getting 0.96 back to a releasable state.
> >
> > Does trunk need a release manager?
> >
> >
> > Comments?
> >
> > -- Lars
> >
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
>

Re: Committing bug and test fixes to branches

[Enis Söztutar <en...@apache.org>]

Branching discussion aside,

I am a big +1 for relying on committers' judgement on whether an issue is
actually a bug fix, and low risk enough, that can be committed to active
branches w/o waiting for RM's approval. Right now committing bug fixes
would require that at least Stack, Lars and Andrew all took a look at the
patch, which is a definite overhead because the commits have to be ordered
as well.

Personally I have been using my judgement already in the past, and I have
not been yelled at by RM's for far : ), I expect committers can manage the
responsibility. If the issue is involved or the risk to benefit ratio is
not clear, we can always ping the RMs as usual. Plus the RM can always do a
reverse review for commits and revert if further discussion is needed I
think.

Enis


On Mon, Jan 6, 2014 at 9:04 AM, Sergey Shelukhin <se...@hortonworks.com>wrote:

> I think there can be problems with features like mvcc-seqId combo being in
> a branch, because they may touch lots of places in the core that might
> change frequently and cause lots of merging/rebasing overhead. So that's
> another thing to consider...
>
>
> On Fri, Jan 3, 2014 at 5:41 PM, Ted Yu <yu...@gmail.com> wrote:
>
> > bq. getting large features or even moderately sized features into
> branches
> > off of trunk
> >
> > +1
> > We should embrace the above model.
> >
> > bq. There are a handful these being worked on
> >
> > I want to mention the unification of mvcc and sequence Id as one more
> such
> > feature.
> >
> > Cheers
> >
> >
> > On Fri, Jan 3, 2014 at 5:32 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
> >
> > > I think I like the idea of a release manger for trunk but is seems
> like a
> > > potentially all-consuming task requiring superhuman vigilance.
> > >
> > > Would working more on feature branches with invested
> > > devs/commiters/shepards is another way of potentially achieving the
> goal
> > of
> > > a releasable trunk?  This could be instead of or in conjunction with
> the
> > > trunk RM idea.
> > >
> > > Trunk would theoretically only get completed features, refactors, or
> bug
> > > fixes and would remain releasable.
> > >
> > > I've been espousing getting large features or even moderately sized
> > > features into branches off of trunk. There are a handful these being
> > worked
> > > on or recently proposed (new master, multi-wal, local 2ndary idx,
> shadow
> > > regions, read replicas, and the visibility tags stuff).Keeping these in
> > > branches reduces the chance that trunk gets into a state with half done
> > > feature.
> > >
> > > Jon
> > >
> > >
> > > On Fri, Jan 3, 2014 at 3:09 PM, lars hofhansl <la...@apache.org>
> wrote:
> > >
> > > > We currently have 4 branches (0.94, 0.96, 0.98, and trunk).
> > > > For bug and test fixes, do we really need the release managers to
> agree
> > > to
> > > > every single check-in.
> > > > Andy
> > > >  currently wants to stabilize the tests in 0.98 so looking at every
> > > > change there makes sense and was specifically requested by him.
> > > >
> > > > What about 0.94, 0.96, and trunk. I do not feel like I need to be
> > pinged
> > > > for every bug/test fix for 0.94.
> > > >
> > > > I
> > > >  would propose that committers use good judgment and commit small
> > > > changes to fix bugs and tests to any branch without a nod from the
> RMs,
> > > > unless specifically request as with 0.98. If we can't trust a
> committer
> > > > with that, (s)he should not be a committer.
> > > > For larger fixes and any new feature the RMs should be pinged of
> > course.
> > > >
> > > >
> > > > Related to this, it seems we're a little loose with trunk as in "It's
> > OK
> > > > it's just trunk". Trunk will become a release eventually and IMHO we
> > > should
> > > > aim for keeping trunk in a releasable state as much as this is
> > possible.
> > > > If we had done that before 0.96, Stack would not have had to face the
> > > > superhuman task of getting 0.96 back to a releasable state.
> > > >
> > > > Does trunk need a release manager?
> > > >
> > > >
> > > > Comments?
> > > >
> > > > -- Lars
> > > >
> > >
> > >
> > >
> > > --
> > > // Jonathan Hsieh (shay)
> > > // Software Engineer, Cloudera
> > > // jon@cloudera.com
> > >
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: Committing bug and test fixes to branches

[Sergey Shelukhin <se...@hortonworks.com>]

I think there can be problems with features like mvcc-seqId combo being in
a branch, because they may touch lots of places in the core that might
change frequently and cause lots of merging/rebasing overhead. So that's
another thing to consider...


On Fri, Jan 3, 2014 at 5:41 PM, Ted Yu <yu...@gmail.com> wrote:

> bq. getting large features or even moderately sized features into branches
> off of trunk
>
> +1
> We should embrace the above model.
>
> bq. There are a handful these being worked on
>
> I want to mention the unification of mvcc and sequence Id as one more such
> feature.
>
> Cheers
>
>
> On Fri, Jan 3, 2014 at 5:32 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
> > I think I like the idea of a release manger for trunk but is seems like a
> > potentially all-consuming task requiring superhuman vigilance.
> >
> > Would working more on feature branches with invested
> > devs/commiters/shepards is another way of potentially achieving the goal
> of
> > a releasable trunk?  This could be instead of or in conjunction with the
> > trunk RM idea.
> >
> > Trunk would theoretically only get completed features, refactors, or bug
> > fixes and would remain releasable.
> >
> > I've been espousing getting large features or even moderately sized
> > features into branches off of trunk. There are a handful these being
> worked
> > on or recently proposed (new master, multi-wal, local 2ndary idx, shadow
> > regions, read replicas, and the visibility tags stuff).Keeping these in
> > branches reduces the chance that trunk gets into a state with half done
> > feature.
> >
> > Jon
> >
> >
> > On Fri, Jan 3, 2014 at 3:09 PM, lars hofhansl <la...@apache.org> wrote:
> >
> > > We currently have 4 branches (0.94, 0.96, 0.98, and trunk).
> > > For bug and test fixes, do we really need the release managers to agree
> > to
> > > every single check-in.
> > > Andy
> > >  currently wants to stabilize the tests in 0.98 so looking at every
> > > change there makes sense and was specifically requested by him.
> > >
> > > What about 0.94, 0.96, and trunk. I do not feel like I need to be
> pinged
> > > for every bug/test fix for 0.94.
> > >
> > > I
> > >  would propose that committers use good judgment and commit small
> > > changes to fix bugs and tests to any branch without a nod from the RMs,
> > > unless specifically request as with 0.98. If we can't trust a committer
> > > with that, (s)he should not be a committer.
> > > For larger fixes and any new feature the RMs should be pinged of
> course.
> > >
> > >
> > > Related to this, it seems we're a little loose with trunk as in "It's
> OK
> > > it's just trunk". Trunk will become a release eventually and IMHO we
> > should
> > > aim for keeping trunk in a releasable state as much as this is
> possible.
> > > If we had done that before 0.96, Stack would not have had to face the
> > > superhuman task of getting 0.96 back to a releasable state.
> > >
> > > Does trunk need a release manager?
> > >
> > >
> > > Comments?
> > >
> > > -- Lars
> > >
> >
> >
> >
> > --
> > // Jonathan Hsieh (shay)
> > // Software Engineer, Cloudera
> > // jon@cloudera.com
> >
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: Committing bug and test fixes to branches

[Ted Yu <yu...@gmail.com>]

bq. getting large features or even moderately sized features into branches
off of trunk

+1
We should embrace the above model.

bq. There are a handful these being worked on

I want to mention the unification of mvcc and sequence Id as one more such
feature.

Cheers


On Fri, Jan 3, 2014 at 5:32 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:

> I think I like the idea of a release manger for trunk but is seems like a
> potentially all-consuming task requiring superhuman vigilance.
>
> Would working more on feature branches with invested
> devs/commiters/shepards is another way of potentially achieving the goal of
> a releasable trunk?  This could be instead of or in conjunction with the
> trunk RM idea.
>
> Trunk would theoretically only get completed features, refactors, or bug
> fixes and would remain releasable.
>
> I've been espousing getting large features or even moderately sized
> features into branches off of trunk. There are a handful these being worked
> on or recently proposed (new master, multi-wal, local 2ndary idx, shadow
> regions, read replicas, and the visibility tags stuff).Keeping these in
> branches reduces the chance that trunk gets into a state with half done
> feature.
>
> Jon
>
>
> On Fri, Jan 3, 2014 at 3:09 PM, lars hofhansl <la...@apache.org> wrote:
>
> > We currently have 4 branches (0.94, 0.96, 0.98, and trunk).
> > For bug and test fixes, do we really need the release managers to agree
> to
> > every single check-in.
> > Andy
> >  currently wants to stabilize the tests in 0.98 so looking at every
> > change there makes sense and was specifically requested by him.
> >
> > What about 0.94, 0.96, and trunk. I do not feel like I need to be pinged
> > for every bug/test fix for 0.94.
> >
> > I
> >  would propose that committers use good judgment and commit small
> > changes to fix bugs and tests to any branch without a nod from the RMs,
> > unless specifically request as with 0.98. If we can't trust a committer
> > with that, (s)he should not be a committer.
> > For larger fixes and any new feature the RMs should be pinged of course.
> >
> >
> > Related to this, it seems we're a little loose with trunk as in "It's OK
> > it's just trunk". Trunk will become a release eventually and IMHO we
> should
> > aim for keeping trunk in a releasable state as much as this is possible.
> > If we had done that before 0.96, Stack would not have had to face the
> > superhuman task of getting 0.96 back to a releasable state.
> >
> > Does trunk need a release manager?
> >
> >
> > Comments?
> >
> > -- Lars
> >
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
>

Re: Committing bug and test fixes to branches

[Jonathan Hsieh <jo...@cloudera.com>]

I think I like the idea of a release manger for trunk but is seems like a
potentially all-consuming task requiring superhuman vigilance.

Would working more on feature branches with invested
devs/commiters/shepards is another way of potentially achieving the goal of
a releasable trunk?  This could be instead of or in conjunction with the
trunk RM idea.

Trunk would theoretically only get completed features, refactors, or bug
fixes and would remain releasable.

I've been espousing getting large features or even moderately sized
features into branches off of trunk. There are a handful these being worked
on or recently proposed (new master, multi-wal, local 2ndary idx, shadow
regions, read replicas, and the visibility tags stuff).Keeping these in
branches reduces the chance that trunk gets into a state with half done
feature.

Jon


On Fri, Jan 3, 2014 at 3:09 PM, lars hofhansl <la...@apache.org> wrote:

> We currently have 4 branches (0.94, 0.96, 0.98, and trunk).
> For bug and test fixes, do we really need the release managers to agree to
> every single check-in.
> Andy
>  currently wants to stabilize the tests in 0.98 so looking at every
> change there makes sense and was specifically requested by him.
>
> What about 0.94, 0.96, and trunk. I do not feel like I need to be pinged
> for every bug/test fix for 0.94.
>
> I
>  would propose that committers use good judgment and commit small
> changes to fix bugs and tests to any branch without a nod from the RMs,
> unless specifically request as with 0.98. If we can't trust a committer
> with that, (s)he should not be a committer.
> For larger fixes and any new feature the RMs should be pinged of course.
>
>
> Related to this, it seems we're a little loose with trunk as in "It's OK
> it's just trunk". Trunk will become a release eventually and IMHO we should
> aim for keeping trunk in a releasable state as much as this is possible.
> If we had done that before 0.96, Stack would not have had to face the
> superhuman task of getting 0.96 back to a releasable state.
>
> Does trunk need a release manager?
>
>
> Comments?
>
> -- Lars
>



-- 
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com

Re: Committing bug and test fixes to branches

[Andrew Purtell <ap...@apache.org>]

I think we should have a volunteer on deck as RM for the next major release
at any given time, and so this person would/should be concerned about the
state of trunk. Good idea.

As for me asking for a "soft freeze" on 0.98, I thank you for your
indulgence and it will be a thing of the past after the 0.98.0 release.


On Fri, Jan 3, 2014 at 3:09 PM, lars hofhansl <la...@apache.org> wrote:

> We currently have 4 branches (0.94, 0.96, 0.98, and trunk).
> For bug and test fixes, do we really need the release managers to agree to
> every single check-in.
> Andy
>  currently wants to stabilize the tests in 0.98 so looking at every
> change there makes sense and was specifically requested by him.
>
> What about 0.94, 0.96, and trunk. I do not feel like I need to be pinged
> for every bug/test fix for 0.94.
>
> I
>  would propose that committers use good judgment and commit small
> changes to fix bugs and tests to any branch without a nod from the RMs,
> unless specifically request as with 0.98. If we can't trust a committer
> with that, (s)he should not be a committer.
> For larger fixes and any new feature the RMs should be pinged of course.
>
>
> Related to this, it seems we're a little loose with trunk as in "It's OK
> it's just trunk". Trunk will become a release eventually and IMHO we should
> aim for keeping trunk in a releasable state as much as this is possible.
> If we had done that before 0.96, Stack would not have had to face the
> superhuman task of getting 0.96 back to a releasable state.
>
> Does trunk need a release manager?
>
>
> Comments?
>
> -- Lars
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)