Updates next steps

[Jesse Keating]

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.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/desktop/attachments/20100423/34e1a4f7/attachment.bin