On Fri, Feb 15, 2013 at 6:32 AM, Platonides <platoni...@gmail.com> wrote: > 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.
We should probably reset the subject again since this is something of a tangent from revoking +2, but since it was brought up, let me clarify the process behind when gerrit reports that someone is doing a self-merge for security fixes (and I welcome input for ways to improve the process!). When we get a report of an xss (assuming isn't not yet "public" or being actively exploited), we file a bugzilla ticket in the security category. Usually me or someone else in that group adds a patch to the bug. Someone else gives a "yes, this looks ok to deploy" comment on the bug. The patch is put into production, backported to the supported release versions, then we release tarballs / patches. When the tarballs are released, I typically submit and merge the patches into master and supported branches, since we have a number of users who pull from git to update their systems. This process is painful (no one like reviewing patches in bugzilla), and the wrangling to get the right people to review patches in bugzilla is slowing down our security releases. It would be much better if we had a way to submit the patches in gerrit, go through the normal review process by a trusted group of developers ending in a +2's, and then the final merge is just a single click when we release the tarballs. But we haven't been able to get gerrit to do that yet (although if any java developers want to work on that, I would be very excited). > 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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
