Thursday, 20 April 2017

Re: SRU quality and preventing regressions

Hash: SHA256

Il 22/03/2017 02:25, Robie Basak ha scritto:
> 1) "Regression Potential"
> "Regression Potential" is supposed to describe:
> 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).

> 2) "verification-done"
> When marking "verification-done", please describe what packages
> were tested and what versions. This is explicitly requested in the
> acceptance message, but I see many people not doing this.
> We have had at least one very severe regression because the
> version tested was not the version released. To prevent this
> happening again, I will continue to bounce back any
> "verification-done" that does not explicitly state what package
> versions were tested.

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.

Version: GnuPG v2.0.22 (GNU/Linux)


ubuntu-devel mailing list
Modify settings or unsubscribe at: