Updates next steps

[Will Woods]

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