Hi, On Sat, 2 Dec 2017 19:14:01 +0100 Julien Cristau <jcris...@debian.org> wrote: > I brought this up in Cambridge, filing here so we can discuss specifics. > > At Mozilla we're using a template in bugzilla [1] for requests to > cherry-pick changes from trunk to a release branch, to help release > management assess reward/risk from specific changes, and I thought > something like that might be useful in Debian too.
I think this is a great idea. > [Feature/Bug causing the regression]: > [User impact if declined]: > [Is this code covered by automated tests?] > [Has the fix been verified in Nightly?] > [Needs manual test from QE? If yes, steps to reproduce]: > [List of other uplifts needed for the feature/fix]: > [Is the change risky?]: > [Why is the change risky/not risky?]: > [String changes made/needed]: > > I think most of it would also be useful here, framed something like: > - when was the bug introduced, is it a regression > - user impact of the bug > - what automated or manual tests cover the affected code > - has the change been verified in sid > - some discussion of the risks involved, if only so the > maintainer/submitter asks themselves that question > - l10n impact - what does it mean if we don't have this in <next-(point-)release> - key package / leaf package - please explain *all* the changes (i.e. a new upstream release is very often *not* a targeted fix) - are *all* the changes documented in the changelog (checklist item) - did you review all the changes personally and what is your judgment? > It can't be too long or it will be a pain for people to write and for us > to read, so maybe we should trim that down a bit, but if we can reduce > the back and forth by having more relevant information in those bug > reports I think that might be useful. Yes. The example below from Ubuntu may be too long. > Ubuntu may have something in their SRU bug process too? https://wiki.ubuntu.com/StableReleaseUpdates says: """ 3.1. SRU Bug Template [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [Test Case] * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. [Regression Potential] * discussion of how regressions are most likely to manifest as a result of this change. * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance """ Paul
signature.asc
Description: OpenPGP digital signature
