Monday, 19 August 2019

Re: StableReleaseUpdates page (Was: Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates)

On Mon, Aug 19, 2019 at 10:05:15PM +0200, Julian Andres Klode wrote:
> - I've uploaded quite a few SRUs by now, and maybe a handful have been (partially)
> verified by someone else. Partially because these people only test their
> favorite release (and then forget to do some tagging changes, or mention
> version numbers), so you still have to do it anyway.
> In practice, people report bugs, and when you push a fix they are gone.

If in doubt about testing commitment I usually try to ask reporters to
commit to doing appropriate testing (making it clear what we need)
before I drive an SRU "for" some particular set of users.

I also don't feel guilty about letting an SRU slide because it isn't
getting verified. The way I see it: if no users care enough to test the
fix, then evidently nobody really needs the fix, so why should we risk
regressing unaffected users?

This obviously doesn't apply to obviously serious bugs, special cases,
and so forth.

I wonder what others think?

> - Basically everyone sets their tasks to "In Progress" when working
> on it, despite "In Progress" being reserved for "fix uploaded to queue".

The docs don't reserve that status, so I always considered "In Progress"
to be acceptable for both cases.

> - People set "Fix committed" when/before an upload, despite it being
> reserved for "fix in -proposed"

Again, the docs don't reserve that status just for that, although in
this case I would agree it's wrong but for a different reason - before
SRU review, we cannot know that the proposed fix, or any fix, really
will land in the archive. The SRU team might reject the SRU itself for
policy reasons, for example. I see this as equivalent to marking "Fix
Committed" when a MP is proposed, before it is reviewed - which we don't