Better mention the release manager when you want to commit to the branch. If no response in a day or so then just go head. At least for 2.1 you can follow this rule.
2018-07-25 11:06 GMT+08:00 Guanghao Zhang <[email protected]>: > 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 <[email protected]>: > > > On Mon, Jul 23, 2018 at 3:44 PM Josh Elser <[email protected]> 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 > > <[email protected] > > > > > > > > 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 <[email protected]> > > > >> 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 < > [email protected] > > > > > > >> 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 > > > >> > > > >> > > > > > > > > > >
