Thanks for clarification, Andrew. I was thinking that it needs RM’s approval to commit to branch-1.2/1.3/1.4, so unless it is a critical/major fix, by default, it goes to branch-1.
It is now clear and I think every committer will follow this best practice. Thanks Huaxiang > On Jul 23, 2018, at 12:47 PM, Andrew Purtell <[email protected]> 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 >> >> > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk
