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? > > > > > > Comments? > > > > -- Lars > > > > > > -- > // Jonathan Hsieh (shay) > // Software Engineer, Cloudera > // [email protected] >
