Refining the update queues/process [Was: Worthless updates]

[Jesse Keating]

On Wed, 2010-03-03 at 09:45 +0100, Till Maas wrote:
> On Tue, Mar 02, 2010 at 11:05:23PM -0800, Jesse Keating wrote:
> > On Wed, 2010-03-03 at 08:02 +0100, Kevin Kofler wrote:
> > > Why? Because you say so? We aren't doing that stuff now and things are 
> > > working just fine, thank you very much! We don't HAVE to change anything at 
> > > all!
> > > 
> > 
> > This I believe to be the crux of the problem.  When multiple updates go
> > out that break large or important segments of our user base, many of us
> > see a problem.  You however seem to think it's "just fine".  Many of us
> > would rather put out a better operating system, and to do that, we need
> > change.  Your "just fine" isn't good enough.
> 
> Are there even any  metrics about how many bad updates happened? For me
> bug that can be fixed issuing an update are a lot more than regressions
> with updates or new bugs introduced with updates. If updates are slowed
> down, this will get even worse. Especially because the proposal is to
> use time instead of test coverage as the criterion to push an update to
> stable.
> 

There are so many "proposals" out there that it's hard to know which
ones we're arguing about.  In fact, none have been presented to FESCo
yet as far as I'm aware.

For me personally the type of update I'd like to see slowed down is the
pure enhancement update or new package updates, ones that do nothing but
swallow up the latest upstream build or scm snapshot to add new
features.  I'm more than happy to see bugfix and security updates go
through, and I don't really buy into time based delays, or time based
only delays.  Karma has a role to play here, even though it is a simple
+1/-1, it is data not otherwise obtained.  If your update gets enough
positive karma 2 hours after it hits updates-testing, by all means push
it to stable.

As far as metrics of bad updates, I don't have any off hand.  We've had
to issue public apologies for screwing up our release in updates more
than once, which is more than once too many times.  We are operating
without a safety net, and we've had some accidents.  I'd like to see a
safety net be put in place, even if to begin with it is a manual safety
net, until such time as AutoQA can take over more and more of the tasks.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100303/03556115/attachment.bin