On Fri, 23 Apr 2010, Owen Taylor wrote:
On Fri, 2010-04-23 at 09:29 -0700, Jesse Keating wrote:
> On Wed, 2010-04-21 at 09:43 -0700, Jesse Keating wrote:
>> On Wed, 2010-04-21 at 12:02 -0400, William Jon McCann wrote:
>>>
>>> 1. Limit the frequency of non-critical updates to once per week in
>>> stable releases
>>>
>>>
>>
>> This gets pretty difficult to manage if we want to insert any testing of
>> the proposed update set to be pushed out. It increases the number of
>> potential push sets, per release, which increases the complexity quite a
>> bit in the depchecking routines.
>>
>> I'm not saying it's something we shouldn't do, I'm just saying
that it's
>> going to make something significantly more complex to manage.
>
> I hate being the "stuff is hard" guy, but I just remembered another
> issue with this. Our update classifications have to be carried forward.
> That is to say, for a given package foo:
>
> foo-1 is shipped in F13.
> foo-2 is an update after F13 went out, and it is a trivial or
> non-critical fix.
> foo-3 is an update that is a critical fix
> foo-4 is a trivial fix
> foo-5 is a new upstream release
>
> The problem is that for people installing f13 after foo-5 was released,
> but want the critical fix for foo, they have to consume foo-5, which
> means consuming all the non-critical changes that happened along the
> way. The same thing happens with security updates. Basically for any
> given package, all the update types for that package become inclusive,
> rather than exclusive. So as the release goes on and a given package
> gets multiple updates, a later update may very well be Critial, Trivial,
> Bugfix, Security, and Enhancement all in one.
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.
I build an update for foo and bar.
foo is a critical update
bar is not a critical update
bar requires that version of foo.
-sv