SRU MOTU Upload Checklist

[Emmet Hikory]

Brandon Holtsclaw wrote:
> Since it seems there has been a bit of confusion over just exactly what
> needs to be done "pre-upload" to -proposed I suggest the folloing list be
> added to the upload step of the wiki and become official policy so there is
> no confusion about -proposed uploads. This list comes after a disscussion
> in #ubuntu-motu just prior to this email if you all care to look back at
> the logs about how we came up with this list and why ( very boring really )
>
> "Patch applies"
> "Result builds"
> "package upgrades cleanly"
> "application runs"
> "reported issue cannot be reproduced"
> "package uninstalls cleanly"
> "package purges cleanly".

Scott Kitterman wrote:
> I would add:
>
> "No regression in the functionality being patched."
>
> This doesn't mean regressions are OK, but that regression testing around
> the change is required.

    I'll suggest that this is not always obvious.  While I agree it is
expected that the person working on the SRU should perform some level
of testing, including ensuring that the application follows expected
behaviour, I am not convinced that a developer workstation is the
ideal environment to ensure there is no regression from the change,
and that proper regression testing will benefit from a wider audience.

    In short, the developer should test some, but shouldn't be shot
because a regression is later discovered (especially for alternate
architectures, specialised hardware, etc.)

Emilio Pozuelo Monfort wrote:
> I would add here "Keep the patch as small as possible", since it is a SRU, which
> is intended to fix a concrete bug. This will probably avoid unexpected regressions.

    This is already documented in the SRU policy, with the phrase "the
patch must be as small and unintrusive as possible".  I do not believe
this needs further stress in the documentation.

-- 
Emmet HIKORY