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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
