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 <olorinb...@gmail.com> 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 <apurt...@apache.org> 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
