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
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
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.
Fedora -- Freedom² is a feature!