On Fri, 2010-04-23 at 13:34 -0400, Owen Taylor wrote: > A feature where you can "subscribe to critical updates only" isn't > necessary here to make a big improvement. > > A strawman might be: > > * We have a set of criteria for what is critical (say security > updates > or fixes breakage in the critical path) > * When you file an update in Bodhi, there's a checkbox for "critical" > * Stuff marked as critical follows the current process > * Stuff not marked as critical is only pushed from updates-testing > to updates on Mondays and goes out on Tuesday morning. > > I don't know the details of the push process, but that seems like it > should be a pretty trivial change to what we do currently. > > Hrm, given that the previous updates are still available that might work. However it would mean we have to differentiate between "what this current update is" vs "what this update is as a union of all previous updates of this package for this release". While today's update of foo is non-critical, the update from last week of foo was critical, and that information needs to be retained in today's update. We can certainly filter our update push types, at least when pushing to stable. I'm hoping that this kind of limited push types is only pushes to stable and shouldn't effect pushes to updates-testing. It's do-able, but as stated before it does add complexity to the puzzle and can create some level of confusion as to why some updates get pushed and others don't. It also leads to some fun failure cases, or rather recovery cases. If a critical update has broken deps unless some other non-critical update is pushed, what do we do? Delay the critical until the non-critical push day, pull in the non-critical? Lots of fun questions to be answered (: -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
