Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Committing bug and test fixes to branches


Copy link to this message
-
Re: Committing bug and test fixes to branches
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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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?
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB