If in your judgement that is what you think is best, that's fine. We are supposed to be doing minors more frequently after all. Mainly I am concerned about trunk being a dumping ground and the lack of rigor in setting fix versions and resolving JIRAs.
For a bug fix relevant for a release branch, though, if you as committer don't put the change into the release branch too and/or forget to update the fix version, then the bug fix may be ignored. This is especially true if the fix is only committed to trunk. Thanks in advance! > On Jul 23, 2018, at 12:52 PM, Huaxiang Sun <[email protected]> wrote: > > 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 >
