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)
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
