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 <yuzhih...@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 <j...@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 > > // j...@cloudera.com > > > >
