hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hsieh <...@cloudera.com>
Subject Re: Committing bug and test fixes to branches
Date Sat, 04 Jan 2014 01:32:25 GMT
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


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message