Changes to the SRU processes?

[Scott Kitterman]

On Wednesday, August 01, 2012 08:55:31 AM Steve Langasek wrote:
> On Wed, Aug 01, 2012 at 02:22:36PM +0200, Sebastien Bacher wrote:
> > Le 31/07/2012 21:36, Brian Murray a écrit :
> > >Oh and if one of the SRU bugs is already tagged
> > >verification-failed it'll just add a comment to that bug. Barring
> > >any objections I'll set this up this week. --
> > 
> > Thanks for working on that. I'm not sure I agree with that though,
> > quite some people run proposed and do notice issues in softwares,
> > while doing SRU testing, which are not regressions, I feel like it
> > will create confusion and makes harder to know which bugs have a
> > confirmed regression and those which just got tagged by side effect
> > of bug filing.
> > 
> > What about adding a new tag verification-potential-regression for
> > those to indicate that the uploader should check those new tickets
> > before the packages got copied to -updates? I don't like to add yet
> > another tag but that one should be only added by a bot and would
> > avoid creating confusion over what verification-failed
> 
> The intent of this process is to ensure that as soon as a potential
> regression has been identified, the SRU process is stopped until someone can
> manually review the facts.  The verification-failed tag fits that
> perfectly, I don't think we need a separate tag.
> 
> In general we should not have packages sitting in -proposed that are
> verification-failed - the SRU team should be driving the list of such
> packages to zero on a regular basis.  So there shouldn't really be any
> confusion here.

We aren't though.

In some cases a package helps some users and causes regressions for others, so 
it's considered "OK" to leave it in proposed while a better fix is developed to 
keep it available for users that it helps.  I'm not sure what we should do in 
those cases.

In other cases it's clear that the update doesn't entirely fix the problem, but 
it's not really a regression either.  In those cases, I think it's generally 
better to release the package to updates, but re-open the bug so the balance 
of the issue can be addressed.

Scott K