Updates next steps

[Owen Taylor]

On Fri, 2010-04-23 at 13:40 -0400, Seth Vidal wrote:
> 
> On Fri, 23 Apr 2010, Owen Taylor wrote:
> 
> > On Fri, 2010-04-23 at 09:29 -0700, Jesse Keating 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 hate being the "stuff is hard" guy, but I just remembered another
> >> issue with this.  Our update classifications have to be carried forward.
> >> That is to say, for a given package foo:
> >>
> >> foo-1 is shipped in F13.
> >> foo-2 is an update after F13 went out, and it is a trivial or
> >> non-critical fix.
> >> foo-3 is an update that is a critical fix
> >> foo-4 is a trivial fix
> >> foo-5 is a new upstream release
> >>
> >> The problem is that for people installing f13 after foo-5 was released,
> >> but want the critical fix for foo, they have to consume foo-5, which
> >> means consuming all the non-critical changes that happened along the
> >> way.  The same thing happens with security updates.  Basically for any
> >> given package, all the update types for that package become inclusive,
> >> rather than exclusive.  So as the release goes on and a given package
> >> gets multiple updates, a later update may very well be Critial, Trivial,
> >> Bugfix, Security, and Enhancement all in one.
> >
> > A feature where you can "subscribe to critical updates only" isn't
> > necessary here to make a big improvement.
> >
> > A strawman might be:
> >
> > * We have a set of criteria for what is critical (say security updates
> >   or fixes breakage in the critical path)
> > * When you file an update in Bodhi, there's a checkbox for "critical"
> > * Stuff marked as critical follows the current process
> > * Stuff not marked as critical is only pushed from updates-testing
> >   to updates on Mondays and goes out on Tuesday morning.
> >
> > I don't know the details of the push process, but that seems like it
> > should be a pretty trivial change to what we do currently.
> 
> I build an update for foo and bar.
> 
> foo is a critical update
> bar is not a critical update
> 
> bar requires that version of foo.

That doesn't seem to be a problem - foo will go out, and bar will wait
until Tuesday. But if you meant the reverse - a critical update that
depends on a non-critical update, then, in my understanding we *already*
have this problem.

If foo and bar are submitted as independent updates, and only bar gets
sufficient karma, or foo is "critical path" and needs releng approval
and bar isn't, then we push bar out and not foo and we have a broken
updates push.

The answer I've heard on this is that foo and bar should have been
submitted as one update. Obviously it would be better if our tooling
could detect this problem and manage it sensibly.

- Owen