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
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
