[csw-maintainers] automated catalog promotion for packages

[Peter FELECAN]

Ben Walton <bwalton at opencsw.org> writes:

> Excerpts from Peter FELECAN's message of Fri Nov 11 08:25:44 -0500 2011:
>
>> Clocking must depend on the entry epoch of the package and not on
>> the REV attribute.
>
> Agreed.  You point out below though that no REV= update would be
> required, but that's not easy to avoid if we're only looking at
> catalog data.  We would stop the clock on a filed bug (meeting defined
> criteria) but in order to restart it for this package, we'd need to
> see it re-enter the catalog.  As we'd never see it actually leave the
> unstable catalog, something detectable must change for it to be
> noticed again.  The REV= stamp of a re-rolled package is the low
> hanging fruit here.  The only other field likely to change is the
> md5sum, or possibly the version field if there is a subsequent update.

In my opinion, the entry epoch is by itself the the sufficient data and
can be part of the package database and/or catalog.

>> > 4. A bug against a dependency if it has a ticking promotion clock too.
>> 
>> I don't get that because a bug for the dependency would stop its
>> clock, isn't it?
>
> If I build against libxml2 and my new program passes the tests, a new
> bug against libxml2 shouldn't hold me up.  But if libxml2 is also new
> (defined by ticking clock here, but that may not be ideal?), and a bug
> is filed against it, packages built against it should (?) be stopped
> as well.  The idea here is that we don't want a situation where I need
> a new SONAME to exist in the next catalog and that doesn't exist
> because the package providing that was held up.
>
> To truly prevent this, we may need to really leverage the pkgdb
> information.

This is still not clear and should be reworked. Maybe a sequence and
state diagram is required here.

>> The Mantis schemata and interface can be changed, it's a practice
>> that I've seen in some places; this will help to keep the current
>> bug tracker with minimal effort, versus changing toward an
>> hypothetically one which is functionally complete.
>
> Replacing the bug tracker is a big project so avoiding it (for now) is
> still a good approach, imo.  If we can bend it to our needs, we
> should.

I agree that changing the bug tracking system is not needed as we can
coerce the current one to do what we wish. The same applies to the other
systems, e.g., version control...

> Aside from augmenting categories/types of bugs, we could also consider
> merging all of the packages into a single item based on their bundle
> tag.  The problem here is that this is relatively new so not all
> packages have it.

Is the bundle concept supported today?

>> > 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?
>> 
>> Quite, but maybe we should add a package attribute explicating the
>> bugs corrected if any; many packaging systems have this very useful
>> information.
>
> I think Debian does something like this.  It's heading in the
> direction of proper change logs  (a required Changelog.CSW in
> $docdir?).  Do you see this as needing to be visible to the promotion
> system?

As RedHat's RPMs

Yes, the bugs addressed by the new release must be visible to the
promotion system as it gives it the ability to decide if a blocking bug
was corrected and restart the clock of dependent packages, &c.

>> > 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.)
>> 
>> No REV stamp difference needed as the clocking is not based on that
>> but on the catalog entry or re-entry time. Consequently, there
>> should be a re-entry procedure, manual, of course.
>
> As I mentioned above, we do need some mechanism to detect the
> difference.  That can be either a drop (where we allow for the cron
> interval to ensure this is seen by the back end) or a re-add with a
> new version/md5sum.  The former is more fragile, imo.

I prefer the the MD5 signature but, in my opinion, the entry epoch is
sufficient.

-- 
Peter