On Feb 15, 2013, at 3:32 PM, Platonides platonides@gmail.com wrote:
I'm not convinced that backporting should be automatically merged, though. Even if the code at REL-old is the same as master (ie. the backport doesn't needs any code change), approving something from master is different than agreeing that it should be merged to REL-old (unless explicitly stated in the previous change). I'm not too firm on that for changes that it's obvious should be backported, such as a XSS fix*, but I would completely oppose to automerge a minor feature because it was merged into master. Note that we are not alone opinating about what it's worth backporting, since downstream distros will also call into question if our new release is “just bugfixes” before they agree into accepting it as-is.
I don't know where you pull "auto-merging" from but it certainly isn't from my e-mail, which was about revoking merge access and about when self-merging may or may not be tolerated.
Auto-merging would imply some random dude can take a change from master merged by someone else *for master*, and submit it to any branch and have it be auto-merged.
What I was talking about is that a code reviewer with merge access can submit an approved change from master to another branch and self-merge it.
Just because one can however doesn't mean one should.
When our random dude pushes a change for review to an old branch that backports a feature from master, the assigned reviewer should (as you explain) not approve it.
And for the same reason, when that reviewer backports himself, he wouldn't self-merge. Or rather, he wouldn't draft such a change in the first place.
-- Krinkle