On Thu, 2010-04-22 at 11:38 -0400, Will Woods wrote: > On Wed, 2010-04-21 at 17:35 -0400, Matthias Clasen 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 don't understand this, tbh. If anything, doing more testing for each > > set of updates would seem to benefit from pushing updates less > > frequently, since it gives us more time to actually test them. Is that > > not the case ? > > I think (correct me if I'm wrong, Jesse) the piece you're missing is > that the 'push' operation is actually fairly tricky for the rel-eng > team: it's time-consuming, error-prone, and doesn't recover from faults > well. It requires a careful shepherd, so to speak. > > So I think the problem Jesse was alluding to is this: Any proposal that > includes dividing updates into different types - and having different > push schedules for different types - means: > > 1) More reasons to push, which could lead to more pushes, and > 2) More subsets of the existing package set(s), which could have a > multiplicative effect on the combinations that need to be tested > > These aren't reasons *not* to do it, and these problems are not > insurmountable. But they're significant technical challenges and thus > important to keep in mind. > > -w > I believe you've hit it Will. Currently there are two sets of potential update pushes for each release, that's A) things going into -testing and B) things going into stable We already see numerous occasions of A requiring something that is going into B, and if you push A without pushing B, you create a broken A. This can't be fixed by grouping updates either, as they can be completely unrelated, but still have a requirement relationship. So things are already complex. Now we're talking about even more potential complexity. A) crit things going into -testing Aa) non-crit things going into -testing B) crit things going into stable Bb) non-crit things going into stable Now we have potential for all sorts of dep issues, where A needs something from Aa or vice versa, or Aa needing a Bb thing, or A needing Bb, or.... This is where the increased complexity in solving out the right set of things to push out. Again this isn't reason not to do this, just an insight into what troubles will be there if we do. -- 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
