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