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