On Feb 15, 2013, at 3:32 PM, Platonides <[email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
