On Fri, 24 Jan 2014 12:39:55 -0800, Adam Williamson wrote: > > https://fedoraproject.org/wiki/Critical_path_package#Actions > > > > | Packages within the critical path are required to perform the > > | most fundamental actions on a system. Those actions include: > > | > > | [...] > > | get updates > > | [...] > > > > > > How to understand that? > > It also says: > > graphical network install > post-install booting > decrypt encrypted filesystems > graphics > login > networking > get updates > minimal buildroot > compose new trees > compose live > > Are we to be expected to re-test every single one of those actions with > every single critical path update? That seems unreasonable. If that were > the approach, I think Kevin would have an actual apoplexy while waiting > for his updates to get released. :) It would be unreasonable for a single tester, but "the more testers, the better". Which doesn't mean the group of testers will perform _all_ of the (re-)tests. It means: the more testers get a chance to apply Test Updates *and* continue using their systems normally for a few days, the more likely it could get that some will notice issues at run-time, boot-time, compile-time, to mention a few. That's why I think there's reason to be very careful and sometimes even prefer a +0 (with a comment) over a very early over-ambitious +1. And guess what happens in non-critpath updates after 7 days and _no_ feedback. Packagers push the update manually. Sometimes with broken deps. Sometimes the testing starts no sooner than when the update arrives in the stable updates repo and the first real user becomes the "guinea pig". > > Is it so hard for testers to slow down a bit until such a system will be > > available? ;-) > > Well, at present, it kind of is, because we have this Bodhi-Bugzilla > interaction where when an update is submitted that claims to fix a given > bug, Bodhi posts a comment on the bug that says 'try this update and > leave positive karma if it fixes your bug'. Good point. Raises the question why an update that links so many bugzilla tickets can be marked stable automatically after a +3, which may be even about a single bz ticket. > I mean, we could tweak that process, but I still think the Grand Bodhi > 2.0 Vision is much more interesting, because if we have multiple karma > types we can still take and use fast 'this fixed my bug' feedback > however we feel it to be appropriate, while having _much_ more > flexibility to do 'valuation' of feedback on a 'type of feedback' and > 'package being updated' basis. Again, hate to sound like a broken > record, but it's just hard to get enthusiastic about trying to twiddle > the edges of the process when the process is fundamentally inadequate. That's understood, of course. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
