So only branch-2.0 need RM's approval. For other release branchs(1.2/1.3/1.4/2.1), they are same with trunk branch and only need one +1 from a committer, right?
2018-07-24 7:37 GMT+08:00 Stack <st...@duboce.net>: > On Mon, Jul 23, 2018 at 3:44 PM Josh Elser <els...@apache.org> wrote: > > > I've been operating under the "get approval" for branch-2.0 since it was > > explicitly asked for. > > > > > Thanks. > > > > > @Stack you still want to operate in that manner since we're chatting > > about this? > > > > > Yeah. Please continue to *synchronize* on me. I want to have final-say on > all that goes into branch-2.0. I have a hard-won understanding of the > general state of this branch and want to keep it in a condition whereby it > continues to pass all nightlies on both hadoop2 and hadoop3. I've been > running tests on a small cluster and have developed understandings around > current perf and scale facility. I am also trying to practice an > important-bug-fixes-only in branch-2.0 policy -- *No Surprises!* -- and > find that my notion of what is an important bug-fix doesn't always jibe > with what others think (smile). In a few cases, i want to try the patch > under load before committing. > > I'm working in this manner because I do not have the bandwidth to do random > spelunking of test/perf or ITBLL failures and so anyone who takes up hbase2 > can be sure there'll be *No Surprises!* on upgrade. I think this tight-hold > on the reins appropriate early in the life of a new major release where we > are trying to earn and keep the trust of users who are thinking of making > the leap from hbase1 to hbase2. > > While this is a little out of line w/ Andrew's lockless, approach, > hopefully I've explained why this approach. Otherwise, +1 on Andrew's ask > for rolling patches back through all branches and an end to chaotic > JIRA'ing. It is pain enough already doing branch compares and if > well-behaved in JIRA, yetus scripts have a chance at automating much of the > RM drudgery. > > S > > > > > > > > > > > > > > > > > > > > On 7/23/18 3:47 PM, Andrew Purtell wrote: > > > Thanks for the great question. > > > > > > I can't speak for every RM, but I believe the answer in general is no, > > you > > > do not need to get the RM's approval. Personally, I only ask that > > > committers hold off when trying to make a release, and only if I need > > time > > > to stabilize the unit tests on a branch. Normally I do a CTR like > review > > > over the commit history in the branch since the last release, and often > > > only in response to unit test failures or API compatibility check > errors. > > > > > > I would encourage everyone on the project to avoid coordination where > > > possible. Coordination is expensive. Use lock free design principles > for > > > both the software and community practices. > > > > > > > > > > > > On Mon, Jul 23, 2018 at 12:42 PM Huaxiang Sun > <h...@cloudera.com.invalid > > > > > > wrote: > > > > > >> Thanks Andrew for bringing this up. I have one following up question. > > >> When pushing to 1.2/1.3/1.4, do we need to get RM's approval? > > >> > > >> Huaxiang > > >> > > >>> On Jul 23, 2018, at 12:24 PM, Andrew Purtell <apurt...@apache.org> > > >> wrote: > > >>> > > >>> I forgot to mention if a commit is only made to master, then the RM > who > > >>> happens to be looking at history has to take on the task of > backporting > > >> the > > >>> change if it turns out to be a bug fix germane to release branches. > The > > >>> worst thing you can do as a committer is take a bug fix change, only > > >> commit > > >>> it to trunk, resolve the JIRA, and walk away. The second worst thing > is > > >> to > > >>> commit only to trunk and leave the JIRA open. There is currently one > > one > > >>> committer doing these things on a frequent basis. I ask that this > > >> practice > > >>> stop. Please view this behavior as poor maintenance practice that > > should > > >> be > > >>> avoided. Frankly, better you not commit the change at all. You are > not > > >>> helping the project. It is a net negative. > > >>> > > >>> On Mon, Jul 23, 2018 at 12:18 PM Andrew Purtell <apurt...@apache.org > > > > >> wrote: > > >>> > > >>>> There is a recent trend in JIRA management where a change being > > tracked > > >> by > > >>>> one JIRA is committed only to master, or maybe master and branch-2, > > and > > >>>> then the JIRA is left open. The fix versions may or may not be > > updated. > > >> The > > >>>> biggest offender is Ted Yu but newer committers are also > occasionally > > >> doing > > >>>> it. Ted has no excuse, the rest is understandable. > > >>>> > > >>>> Please be advised this makes release management difficult. The RM > has > > to > > >>>> look at every commit in the repository and then make sure JIRA > > reflects > > >> the > > >>>> correct fix version. Otherwise the generated change log for the > > release > > >>>> will be incorrect. If more patches are pending for other branches, > and > > >> the > > >>>> fix versions are not set correctly, then the RM may miss the patch > and > > >> not > > >>>> include it into the release. > > >>>> > > >>>> This is the best practice: > > >>>> > > >>>> 1. Set the fix versions for all relevant branches on the JIRA > > >>>> 2. Assemble patches for all relevant branches on the JIRA > > >>>> 3. Commit all of the patches at once to all relevant branches > > >>>> 4. Mark the JIRA resolved > > >>>> > > >>>> I understand there are a lot of branches now, and some changes > require > > >>>> backports. In this case, commit the patch at hand to the branches it > > >> will > > >>>> apply to, then open a new JIRA (could be as a subtask) for the > > backport. > > >>>> Make sure to set fix versions appropriately so the RMs will see it. > > >>>> > > >>>> If our slipping JIRA discipline is not improved we will have > incorrect > > >>>> release change logs, fewer releases, releases missing changes they > > >> should > > >>>> include, and other poor outcomes. > > >>>> > > >>>> -- > > >>>> Best regards, > > >>>> Andrew > > >>>> > > >>>> Words like orphans lost among the crosstalk, meaning torn from > truth's > > >>>> decrepit hands > > >>>> - A23, Crosstalk > > >>>> > > >>> > > >>> > > >>> -- > > >>> Best regards, > > >>> Andrew > > >>> > > >>> Words like orphans lost among the crosstalk, meaning torn from > truth's > > >>> decrepit hands > > >>> - A23, Crosstalk > > >> > > >> > > > > > >
