Updates Criteria Summary/Brainstorming

Michael Schwendt mschwendt at gmail.com
Thu Nov 25 10:12:43 UTC 2010

On Tue, 23 Nov 2010 18:55:38 +0100, Kevin wrote:

> Mike Fedyk wrote:
> > Install package from updates-testing, then +1 to karma after it works
> > for you with your tests and normal workload.
> The average user won't even KNOW there's an update available in updates-
> testing before it's too late (i.e. all his/her data is gone, (s)he asks on 
> forums or IRC what's up, and people point him/her to the testing update 
> (which doesn't help because all the data is already corrupted/deleted!), at 
> which point (s)he'll switch to Ubuntu or Window$ in disgust and swear to 
> never use Fedora again).

That can't be the full story.

The distribution is based upon a long development period including several
test releases. Are you trying to say that this data-eating-bug manages to
slip through the cracks only for Fedora and not "Ubuntu or Window$"?
I cannot believe that. This part of the thread is a lost cause already,
if we want to go down that road while trying to fight for more freedom to
decide on whether/when to push a stable update. :-/ Ubuntu contains plenty
of packages with a large list of active bugs, which are not fixed with
updates. Certainly not in a "ASAP" manner.

> > No need to foist possibly broken software on everyone.
> That's exactly why bugs must be fixed ASAP!

And a flood of rushed updates, which moves away farther from the
originally tested "final" distribution, increases the risk that additional
bugs "must be fixed ASAP". That's going in circles. It's correct to pull up
a fence and try to find more bugs prior to release of the dist *and* the

Returning to the topic, a new criterion for the updates acceptance could
lower the hurdles for updates, which only patch the software (or the spec
file) compared with the previous package release. That is, no attempts at
hiding a version upgrade in a large scm-snapshot-patch, and no "supposedly
minor version bump" which contains some fixes actually but also breaks
something else (such as the infamous unexpected ABI/API breaks).

More information about the devel mailing list