hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <la...@apache.org>
Subject Re: Committing bug and test fixes to branches
Date Sat, 04 Jan 2014 04:56:19 GMT
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 <yuzhihong@gmail.com>
To: "dev@hbase.apache.org" <dev@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 <jon@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 <larsh@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
>


Mime
View raw message