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 > >> > >> > > >
