On Fri, 2010-04-23 at 13:34 -0400, Owen Taylor wrote:
A feature where you can "subscribe to critical updates
necessary here to make a big improvement.
A strawman might be:
* We have a set of criteria for what is critical (say security
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 (:
Fedora -- Freedom² is a feature!