On 15/02/13 01:38, Brad Jorsch wrote: > I'd propose one more: > > * Someone else gives +2, but Jenkins rejects it because it needs a > rebase that is not quite trivial enough for it to do it automatically. > For example, something in RELEASE-NOTES-1.21.
Seems a better example. 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. * Still, we could be making a complete new class in master but just stripping the vulnerable piece in the old release. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
