I've been operating under the "get approval" for branch-2.0 since it was
explicitly asked for.
@Stack you still want to operate in that manner since we're chatting
about this?
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
