On Thu, Apr 20, 2017 at 06:39:15PM +0800, Marco Trevisan wrote:
> Il 22/03/2017 02:25, Robie Basak ha scritto:
> > 1) "Regression Potential"
> >
> > "Regression Potential" is supposed to describe:
> >
> > ...how regressions are most likely to manifest, or may manifest
> > even if it is unlikely, 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.
> >
> > Note that "Low" or "None", or an explanation of why it is "Low" or
> > "None", is insufficient and doesn't meet this requirement.
>
> This is true... But you've to admit that there are fixes where it's
> just not possible to think a regression... Like an obvious
> null-pointer deference fix. That could just make things not to crash
> (unless the code path won't lead to somewhere else unwanted, but I'm
> thinking to the simplest case).
Well, see https://wiki.ubuntu.com/StableReleaseUpdates#Why and bugs
81125, 309674 and 559822. The act of rebuilding can cause a regression.
Build dependencies might have changed, or something might be racing, or
there may be packaging interactions because the package version string
has changed. I think it's worth considering these and similar
possibilities and how this kind of thing may relate to a particular SRU,
and it'll give the SRU team more confidence that thought has been put
into not regressing users.
Most of the time I see "None", I can think of more likely causes than
these that are specific to the situation.
Remember the point of this is to inform SRU verification. We want to
know where to look when testing.
> Ok, that makes sense... However having a pattern to follow and an SRU
> bug template also for verifying would help a lot.
> In the same way we've for opening an SRU bug.
>
> So I hope the SRU team could update the wiki with such informations.
Do you think people would look at the wiki at this stage? Or do you
think we need to amend the verification instructions provided
automatically in the bug comments?
I want three things:
1) What package name and version string was tested (saying "the one from
xenial-proposed" isn't enough for me, as this is where we see things
going wrong as that version can change).
2) What testing was done (saying "the test case from the bug
description" or similar is fine). If extra testing was agreed when the
SRU was accepted, then it is useful to call that out explicitly as done
so that we don't have to ask to make sure.
3) What the result was (saying "tests passed as expected" or similar is
fine).
Robie
