Updates Criteria Summary/Brainstorming

Michael Schwendt mschwendt at gmail.com
Wed Nov 24 20:06:18 UTC 2010

On Mon, 22 Nov 2010 16:01:49 +0100, Kevin wrote:

> I think it's a big mistake to provide only second-class support for 
> Fn-1. The assertion that that's what the people on Fn-1 want is just 
> unfounded, based on a misunderstanding of why people use Fn-1.

There are not enough [human] resources to update Fn-1 in any way it would
be close[r] to the current release. You can observe it everywhere (even by
drawing conclusions about ABRT reports) that Fn-2 is abandoned by our
users months before its EOL date.

Anybody who disagrees is welcome to sign up as a proventester and focus on
Fn-2, particularly the base packages (ex-"Core"). Same applies to Fn-1.
Where are its users? Some perform an upgrade to Fn-1 very late, because
they are overly pessimistic and think the current release is not ready yet.
Those are not users, who would enjoy taking a look at updates-testing.
If they did, they would abandon Fn-1 and upgrade to the latest greatest,
which is the [only] way forward.

> > this could help, but it's not always possible to add these test cases. One
> > example: imap server package - new bug that can corrupt mail folders in
> > some circumstances. Maintainer updates package and sets 'type=bugfix' in
> > bodhi, but not always it's possible to write down any test case. It's
> > still a bug fix and it's better to be delivered sooner than wait if anyone
> > out there get's his mail folders corrupted. Actual policy does not help
> > proactivity.
> Right, and the big point there should be that a bug which can corrupt mail 
> folders should be fixed IMMEDIATELY, i.e. with a direct stable push! ANY 
> testing requirement there is a failure.

> >> Other concrete ideas?
> > 
> > let maintainer decide, punish (enforce any policy) only those maintainers
> > who breaks something, not all innocent group
> +1!

Nothing I would back up without learning about the _details_, please.
How to determine when to blame the package maintainer? What would your
rule set look like?

If a nightmare bug affects a significant number of users, it should be
easier to find at least _one_ such user, who would block the update while
it's in updates-testing, right? But how long to wait for that user to
allocate time for the testing? What piece of the puzzle am I missing?

More information about the devel mailing list