[csw-maintainers] automated catalog promotion for packages

[Geoff Davis]

On 11/10/2011 7:25 PM, Ben Walton wrote:
> Hi All,
>
> At this point, we have automated all of the tasks required for
> automated package publishing to the point where our previous
> mechanisms stopped.  It's now time to start looking at the last piece:
> Package promotion from unstable.
>
> This is by no means a trivial task, so lets hash out the rules that we
> expect from the system.  For the sake of discussion, we'll assume that
> things must bake in unstable for X amount of time.  We'd talked about
> a 2 week duration but that isn't set in stone.  As it doesn't matter
> for this purpose, let's ignore it for now.
>
> I'm going to sketch out the basics of how I see this working.  Then we
> can start picking it apart and finding the edge cases that will make
> it challenging to implement.
>
> Do we agree that all package removals should be done manually or does
> anyone think this should be done automatically too?
>
> For package adds and updates we'll need to determine the point in time
> that a package (add or update) enters the unstable catalog.  The
> simplistic view would use the REV= date stamp for adds/updates but
> that can be misleading as a package might sit in experimental for an
> unknown amount of time before being pushed.  Thus we need to watch the
> catalog(s) and detect package entry.  This is easy enough to do as we
> have machinery for this task already.  The initial spotting of a new
> package should trigger a clock for this package that upon expiry will
> see it moved forward.
>
> What criteria can be used to stop the clock?  Some of the following
> are obvious and some are possibilities.  I'm sure I'm missing items
> here too.
>
> 1. A bug against the package in question.
> 2. A bug against another package in the same 'bundle.'
> 3. A subsequent update of the same package.
> 4. A bug against a dependency if it has a ticking promotion clock too.
>
> All of the bug-based items are complicated by the fact that mantis
> carries no information about which catalog the particular bug is
> relevant too.  A bug could be filed against the package in the named
> release, not the version in unstable but we have no way to ascertain
> that currently.
>
> To handle the mantis limitations, we could either add a facility to
> the promotion tool to ignore various bug id's (a manual action) or
> look at alternate bug tracking systems.
>
> The first item, barring the limitations, is a no brainer.  A bug stops
> the clock.  The question here is whether we remove this package from
> our (long lived) promotion object outright or mark it stalled?  If we
> remove it outright then the third action would never occur...we'd just
> see another new package later on.  If we do this, the 'override this
> bug' mechanism would need to repopulate this entry into the promotion
> object instead of just marking a bug as ignorable.  Leaving the bug in
> the object but marking it stalled has impact on subsequent spottings
> of the same package.
>
> A subsequent update of the same package could simply overwrite the
> existing entry in the current promotion tracking object.  That would
> be the equivalent of saying "we assume that a new update addresses
> open bugs.  it would require a new bug to stop the clock again."  Does
> that seem like a valid assumption to build in?
>
> I think the dependency issue will be the biggest trap here.  I think
> we need to track bugs on dependencies as a broken dep could mean a
> broken app.  We may want to only consider deps that also have ticking
> clocks.  This would allow for the fact that the package under
> consideration was built against the dep (library, etc) that is already
> in the named release catalog.  A dep that pre-exists in the promotion
> object would (assuming we keep the buildfarm very fresh) mean that the
> new package was built against the dep package that has a ticking clock
> itself.
>
> We could choose to ignore dependencies, but I'm not sure that's a good
> idea.
>
> If we decide that blocking a package based on its dependencies is the
> best action, then we have further complications.  An update of the
> dependent package must also remove the block that it set on the
> original.  I guess that's more of a bookkeeping issue in the data
> structure than a hard challenge but it's still something to consider.
>
> We should also offer a mechanism for a maintainer to signal that a
> package is not suitable for promotion.  That could come in the form of
> a bug filed or through a command that is run.  I think filing a bug is
> more consistent (and visible) in this case.
>
> Now, if we end up with several packages in the promotion object that
> have stopped clocks, we'll want to eventually garbage collect them.
> We should be able to set quite a long expiry time on this but at some
> point, things will fall out the bottom.  Do we need a way for the
> maintainer to signal that the clock should start again?  I think the
> simplest way to achieve that is to have the maintainer submit the
> package again and start a new clock.  (This would require a different
> REV= stamp to ensure it is detected.)
>
> Now, what about different architectures and os releases?  The bug
> system isn't granular enough to pick out this info so I think we need
> to stall the package in all catalogs until the normal criteria are
> met.  This would have the benefit of keeping catalogs in lock step
> which I think is a good thing.
>
> I'm probably missing a bunch of important stuff here...
>
> Thoughts and comments?
>
> Thanks
> -Ben
>
>
> --
> Ben Walton
> Systems Programmer - CHASS
> University of Toronto
> C:416.407.5610 | W:416.978.4302
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
While I can't speak for all of the arcanery behind our bug filing 
process, I'd like to point out the case where someone files a bug 
requesting an upgrade of a package. Those types of bugs should not 
normally block promotion of a previous version of a package. I guess it 
should block if it's a security consideration or something like that, 
but a request to go to Cfengine 3 should not block a Cfengine 2 package 
for example.