Updates next steps

[Seth Vidal]

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