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
