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 -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
