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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
