> 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.
One change would be more scrutiny of the stability and function of branch-1 (or other nonreleasing branch like branch-2) after such commit and potential for revert if a regression is not addressed within a reasonable timeframe. We don't have that today. > If we have branch RMs, who should make a decision that if we need to > backport a new feature to branch-x? If it were me I would simply (re)open a JIRA and put up a patch to review, which would be committed after a +1. If I didn't get any response after a few days I might take that as lazy consensus for backport and commit. Someone could -1 or ask for a revert at any time, no problem. For branch-1 if a change didn't meet the compatibility guidelines for inclusion in a minor release or could not be modified to conform than it would be excluded of course. So it is the community process (committers) that decides. What's new is someone more active with testing and shepherding. > Do we have a plan that how often we cut a new releasing branch? When I was RM of 98 we had a minor release roughly every month. I don't think we want that here if each 1.x or 2.x minor is going to have its own RM and be maintained for a long time. Too many versions would proliferate. Or, we could become more like Phoenix, which focuses on making new minors every release cycle and rarely puts out just a patch release, only if there is a serious problem. If we were more like this, someone would volunteer to RM a new minor, it would be branched, tested, then released, and we'd move the stable pointer and all move on. > On Jan 9, 2017, at 12:01 AM, Phil Yang <[email protected]> wrote: > > 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 >>> >>
