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