Like this idea. I think it will help us making non-releasing branches more stable, and reduce delay from cutting releasing branch to release first x.y.0 version which means users will meet new features earlier :)
And I have two questions :) > Occasional sweep through master history looking for appropriate candidates for backport to branch-1, execution of said backport Now the authors of every issues backport new features to branch-1 after they have a patch for master, and committers help them push patches to git. So usually master and branch-1 introduce two patches for a issue at time same time. If we have branch RMs, who should make a decision that if we need to backport a new feature to branch-x? And when we do the backport work? If we have branch-RMs helping us make non-releasing branches more stable, we may be able to cutting new releasing branch more regular? Do we have a plan that how often we cut a new releasing branch? Thanks, Phil 2017-01-07 11:15 GMT+08:00 Ted Yu <[email protected]>: > bq. to see branch-1 be our new long term stable branch > > I agree. > Having an experienced PMC shepherding branch-1 would lay good foundation > for future 1.4+ and 2.x releases. > > +1 with Andrew taking up this role. > > Cheers > > On Fri, Jan 6, 2017 at 6:07 PM, Andrew Purtell <[email protected]> > wrote: > > > I would like to see branch-1 be our new long term stable branch and so to > > be maintained for roughly as long as 0.98 was: three years from first > > release (1.0.0). > > > > It would be maintained the same way as 0.98 was. I would like to drive > > monthly releases but they would only be -SNAPSHOT and never advertised as > > an official release. So to get actual shipping code I guess I'd have to > bug > > the release RMs (smile). > > > > If the branch-1 RM felt like sweeping up changes and backporting for as > > long as he/she likes that would be fine with me. If I were branch-1 RM I > > would do that on a monthly basis. Only changes allowable on minor or > point > > revisions according to our compatibility guidelines would be allowed. > > > > We don't have a release branch RM for 1.4. I would be happy to take on > > that role too, but I think it premature given 1.3.0 isn't even out yet. > > > > > > > On Jan 6, 2017, at 5:43 PM, Mikhail Antonov <[email protected]> > > wrote: > > > > > > I like this idea in general (and thanks for volunteering!). > > > > > > Speaking specifically about branch-1 and given 2.0 release > > > discussions, is it proper time/thread to also discuss what > > > do we want to do with branch-1? Like, say that 1.4 would be > > > the last release off this line and hence branch-1 should be > > > turned to 1.4, and should we wind down backports to it? > > > > > > -Mikhail > > > > > >> On Fri, Jan 6, 2017 at 5:06 PM, Andrew Purtell <[email protected]> > > wrote: > > >> > > >> HBasers, > > >> > > >> I would like to propose extending our informal "branch RM" concept > just > > a > > >> bit to include the nonreleasing branches like branch-1, branch-2 (when > > it > > >> exists), and master. These branches are where all commits are made > > passing > > >> through down to the releasing branches targeted for the change (like, > > >> branch-1.1, branch-1.2, branch-1.3, etc.) > > >> > > >> The releasing branches all have their own RM. I assume that RM is > > >> diligently monitoring its state, by way of review of commit history, > > >> occasional execution of the unit test suite, occasional execution of > the > > >> integration tests, and has perhaps some automation in place to help > with > > >> that on a nightly or weekly basis. No matter, let's assume there is a > > >> nonzero level of scrutiny applied to them, which leads to feedback to > > >> committers about inappropriate commits via compat guidelines, commits > > which > > >> have broken unit tests, or other indications of quality or functional > > >> concerns. I think it would improve our overall velocity as a project > > if we > > >> could also have volunteers tending the development branches upstream > > from > > >> the releasing branches. Less work would fall to the RMs tending the > > release > > >> branches if a common troublesome commit can be caught upstream first. > In > > >> particular I am thinking about branch-1. > > >> > > >> I would like to volunteer to become the new RM for branch-1, to test > and > > >> refine my above proposal in practice. Unless I hear objections I will > > >> assume by lazy consensus everyone is ok with this experiment. > > >> > > >> What this would mean: > > >> > > >> - JIRAs like "TestFooBar is broken on branch-1" will show up sooner, > > and > > >> more likely with fix patches > > >> - Semiregular performance reports on branch-1 code as of date X/Y/Z, > > can > > >> compare with earlier reports for trending > > >> - Occasional sweep through master history looking for appropriate > > >> candidates for backport to branch-1, execution of said backport > > >> - Occasional 1B row ITBLL torture tests, probably if failure with > > bisect > > >> back to commit that introduced instability > > >> > > >> What this does not mean: > > >> > > >> - The branch-1 RM will not attempt to tell other branch RMs what or > > what > > >> not to include in their release branches > > >> - The branch-1 RM won't commit anything backported from master to > any > > of > > >> the release branches; it will continue to be up to the release > branch > > >> RMs > > >> what they would or would not like to be included > > >> > > >> Also, I don't see why I couldn't spend some time looking at master > now > > and > > >> then. > > >> > > >> I am going to assume our current co-RM team for branch-2 would maybe > do > > >> something similar for branch-2, once it materializes. > > >> > > >> Thoughts? Comments? Concerns? > > >> > > >> > > >> > > >> > > >> -- > > >> Best regards, > > >> > > >> - Andy > > >> > > >> If you are given a choice, you believe you have acted freely. - > Raymond > > >> Teller (via Peter Watts) > > >> > > > > > > > > > > > > -- > > > Thanks, > > > Michael Antonov > > >
