On Tue, Mar 31, 2009 at 2:58 AM, Manuel Wolfshant <[email protected]> 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? _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
