On Thu, Dec 11, 2008 at 3:27 PM, Bill Davidsen <davidsen@xxxxxxx> wrote: > This one was a special case, not intended to go out so quickly, but a policy > change would be welcome, to assure testing of new packages, at least for > obvious things like permissions, missing requirements, and "won't even > ____ing boot!" cases. A policy change? What policy change? You want to take away the ability for maintainers to rush updates to stable completely? That's going to be sell compared to the tradeoffs of getting a security update out quickly. Adding more signoffs to do that sort of thing is going to just delay important security responses. dbus was tagged as security btw...it just wasn't intended for stable. Are you using updates-testing on any of machines? Are you using updates-testing on enough enough machines to test hardware dependant problems which could bite you? Are you submitting affirmative feedback in bodhi about updates-testing packages you install? Even non-booting cases can be quite difficult because they are invariably hardware dependant. If it boots in my F-9 virtual machine for example...is it going to boot on your iron? Even if we had automated testing for "does it still boot" would probably pass because those tests are going to be done in virtualized systems. Passing the automated tests may not give us much more info that standard developer testing. Any hardware regression can be difficult to catch. If my laptop camera still works after an update, is it gonna still work for yours? Hardware regressions are so very much a pain that can only be addressed with exceptional testing coverage. Those are the sort of things that the 'right' people have to be 'lucky' enough to experience to identify before they can be addressed. The only way we can prevent users in stable from seeing problems is if more users volunteer to use updates-testing. I should generate some metrics from mirrormanager about the number of people with updates-testing enabled compared to updates. -jef -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
