stable pushes in the bodhi world

[Jon Stanley]

On Tue, Mar 31, 2009 at 2:58 AM, Manuel Wolfshant
<wolfy at nobugconsulting.ro> wrote:

> Feel free to propose a shoter delay, or another mechanism. I just suggested
> a default fallback in order to be sure that the packages do not stay forever
> in testing. We are all open to suggestions, aren't we ?

Sorry, it was late last night and now I realize that I just committed
one of my pet peeves on mailing lists - said something was no good
without a concrete plan to improve it :)

So here's what I'd suggest, which is somewhat how it happens in Fedora
today (though with less review in Fedora than I'd propose in EPEL)

Maintainer does build in koji, then submits the update.  It's up to
the maintainers discretion whether to submit the update to testing or
stable.  Builds that aren't in bodhi remain available via koji (until
garbage collection makes them go away) in a tag like
dist-5E-epel-candidate

A submission directly to stable should raise some eyebrows - like
security updates which have CVE attached, etc. Anything else (other
than newpackage) should probably be rejected for pushing directly to
stable.  A karma of +3 is sufficient to automatically move an update
from testing to stable.  These stable pushes should occur weekly.

If there's been no karma given to an update (and it therefore hasn't
been auto-pushed as above), then the maintainer should get poked about
it after 2-4 weeks in testing.  I get mails from bodhi all the time
that something of mine is languishing in updates-testing in Fedora
because I forgot about them.  The key here is that some affirmative
step needs to be taken by the maintainer in order for the update to
show up in stable - maybe the maintainer actually has a specific
reason that they don't want it in stable.

So there's a workable suggestion :)

One thing that I don't know about, which is brought up by Mike's
Nagios thread, is that what do we do about "guaranteeing" ABI/config
file format compatibility within a release? RHEL obviously has strict
rules on that, do we need to be so strict, or is simply an
announcement OK that "yo, XYZ is changing!".  The concern that I have
is that most of our users are likely not subscribed to this list, nor
to the new epel-announce.  So imagine the user experience - folks use
our repository, expecting compatibility, do a yum update, and all of a
sudden their stuff is broken.

Perhaps there's room in there to just leave it in testing, and if you
use testing and it breaks, you get to keep all the pieces.

Thoughts on that one?