Hi Nathan,
thanks for your feedback and comments! Please see my replies inline.
On 2020-03-24 17:04, Nathan Cutler wrote:
Based on my experience with how folks comply with the
current backporting rules,
I would not trust very many people (you are one of the exceptions!) to adhere to
this rule that bugfixes should be merged into master after fixing in octopus.
My expectation is that, once the a bug is fixed in octopus the second part
(merging into master) will be forgotten in many cases. After all, as you say:
that's the "actual branch that is currently used by the community" and once
the
bug is fixed there, the immediate thorn-in-the-side is gone!
That's indeed a good point. Both ways depend on manual intervention and
tracking, but the current way has a built-in motivation factor (as the
fix needs to be applied to the affected branches explicitly). One option
of doing this would be to mandate a corresponding merge PR into master
to be always submitted along with the bug fix PR into the octopus
branch, but then one would have to keep multiple PRs updated in
parallel. I agree this will be challenging.
Another thing I have learned is that any rule, in
order to be effective, must be
policed. With the current horribly-imperfect-but-it's-what-we-have system, when
someone opens a PR targeting nautilus and we see that it's "original
research"
(to borrow a term from Wikipedia), we immediately see that. Policing is
relatively easy - we see at first glance that it's not a cherry-pick. Thanks to
GitHub, we can easily click on the SHA1 and check if it's present in the master
branch.
It sounds like your proposed new system is expecting developers will always
remember to forward-port to master *after* their bug has been fixed (or feature
implemented). But is that a realistic expectation? Would it be prudent to
include some reminder/enforcement mechanism? If so, how would it work?
Well, one way of doing this is to have a job that compares the octopus
branch with the master branch and reports all currently unmerged
changesets and their authors. Actually, once a PR has been merged into
octopus, we could set up a trigger job that automatically prepares a
merge PR of that changeset into the master branch and opens it for
review/approval, assigned to the original author.
This way, they don't have to perform the work locally themselves. If the
PR is in a mergeable state, propagating it into master is
straightforward. If more changes/modifications are necessary, a
developer could create a local clone of that branch and perform any
required fixes/updates.
Would that be feasible?
Lenz
--
SUSE Software Solutions Germany GmbH - Maxfeldstr. 5 - 90409 Nuernberg
GF: Felix Imendörffer, HRB 36809 (AG Nürnberg)