Greetings.
In the EPEL meeting today (yes, we had one finally!) the question came up of how often we would want to do stable pushes after we have gotten koji and bodhi all working for EPEL.
Currently:
- Maintainers build and their packages go to testing. - After (loosely) 1 month, the package is just moved to stable unless the maintainer specifically tells the signers not to push it.
Note that this doesn't mean it's gotten any testing or is really 'stable', it just means no one yelled that was using testing. ;) Or at least not loud enough to stop it.
Moving forward:
- Maintainer will build and request testing for their package. - Testers can provide karma/comments. - At some point the maintainer decides based on these that the package is stable and stable is requested. - Signers push the stable updates.
There are a number of questions here:
1. How often should stable pushes be done by signers: a) monthly just as it is now. b) weekly c) more often
With a) we have the advantage of a specific time that folks expect stable updates to appear, but we also have known stable packages waiting in testing that could be in stable.
With b) we lessen the wait time, but increase the times people expect updates.
With c) the wait time is very low, but no one knows when stable updates will appear.
2. Should we require some level of bodhi feedback to push something to stable? If we can't find a few people to +1 an update should it just stay in testing until it gets the needed karma? The bad side here is that if we don't have enough people testing, some stable software will languish in testing.
Input on these questions welcome, they need to be decided before koji/bodhi go live for epel.
kevin
On 03/28/2009 12:00 AM, Kevin Fenzi wrote:
Greetings.
In the EPEL meeting today (yes, we had one finally!) the question came up of how often we would want to do stable pushes after we have gotten koji and bodhi all working for EPEL.
Currently:
- Maintainers build and their packages go to testing.
- After (loosely) 1 month, the package is just moved to stable unless the maintainer specifically tells the signers not to push it.
Note that this doesn't mean it's gotten any testing or is really 'stable', it just means no one yelled that was using testing. ;) Or at least not loud enough to stop it.
Moving forward:
- Maintainer will build and request testing for their package.
- Testers can provide karma/comments.
- At some point the maintainer decides based on these that the package is stable and stable is requested.
- Signers push the stable updates.
There are a number of questions here:
- How often should stable pushes be done by signers:
a) monthly just as it is now. b) weekly c) more often
With a) we have the advantage of a specific time that folks expect stable updates to appear, but we also have known stable packages waiting in testing that could be in stable.
With b) we lessen the wait time, but increase the times people expect updates.
With c) the wait time is very low, but no one knows when stable updates will appear.
- Should we require some level of bodhi feedback to push something to
stable? If we can't find a few people to +1 an update should it just stay in testing until it gets the needed karma? The bad side here is that if we don't have enough people testing, some stable software will languish in testing.
Input on these questions welcome, they need to be decided before koji/bodhi go live for epel.
I'd suggest: - pushes occur once per month and take into account the following 3 rules: 1. at least one month in testing, as we have now (unless security fix) 2. push to stable if karma reaches a level N>0 ("N" to be defined) and time in testing >= 4 weeks 3. push to stable if karma >=0 and the package was in testing "long enough" (not less than 4 weeks; maybe 12 ?)
On Sun, 29 Mar 2009 19:41:20 +0300 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
I'd suggest:
- pushes occur once per month and take into account the following 3
rules: 1. at least one month in testing, as we have now (unless security fix) 2. push to stable if karma reaches a level N>0 ("N" to be defined) and time in testing >= 4 weeks 3. push to stable if karma >=0 and the package was in testing "long enough" (not less than 4 weeks; maybe 12 ?)
So, this would be a slower progression than we have now, right?
And how many people are we likely to have add karma? It seems not too used in the Fedora world, and I am sure there are fewer EPEL users. ;)
Any other input out there?
kevin
2009/3/29 Kevin Fenzi kevin@scrye.com:
On Sun, 29 Mar 2009 19:41:20 +0300 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
I'd suggest:
- pushes occur once per month and take into account the following 3
rules: 1. at least one month in testing, as we have now (unless security fix) 2. push to stable if karma reaches a level N>0 ("N" to be defined) and time in testing >= 4 weeks 3. push to stable if karma >=0 and the package was in testing "long enough" (not less than 4 weeks; maybe 12 ?)
So, this would be a slower progression than we have now, right?
Slow isn't the same thing as stable, I think we need to remember that.
And how many people are we likely to have add karma? It seems not too used in the Fedora world, and I am sure there are fewer EPEL users. ;)
Any other input out there?
I was thinking this too. Many package I use/maintain have a small user-base. So, the likelyhood of Karma happening is nil. In Fedora it doesn't happen, and in EPEL I am nearly positive it won't.
kevin
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On 03/31/2009 02:33 AM, Michael Stahnke wrote:
2009/3/29 Kevin Fenzi kevin@scrye.com:
On Sun, 29 Mar 2009 19:41:20 +0300 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
I'd suggest:
- pushes occur once per month and take into account the following 3
rules: 1. at least one month in testing, as we have now (unless security fix) 2. push to stable if karma reaches a level N>0 ("N" to be defined) and time in testing >= 4 weeks 3. push to stable if karma >=0 and the package was in testing "long enough" (not less than 4 weeks; maybe 12 ?)
So, this would be a slower progression than we have now, right?
Slow isn't the same thing as stable, I think we need to remember that.
And how many people are we likely to have add karma? It seems not too used in the Fedora world, and I am sure there are fewer EPEL users. ;)
Any other input out there?
I was thinking this too. Many package I use/maintain have a small user-base. So, the likelyhood of Karma happening is nil. In Fedora it doesn't happen, and in EPEL I am nearly positive it won't.
which is why I suggested the automatic push (unless the package exhibited problems and received negative karma) after 3 months. which is half the release cycle of the main distro.
On Mon, Mar 30, 2009 at 7:37 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
which is why I suggested the automatic push (unless the package exhibited problems and received negative karma) after 3 months. which is half the release cycle of the main distro.
I still don't think that's a good idea. I maintain a few niche packages (supybot-fedora and supybot-koji) which are semi-critical to Fedora infrastructure (provides very easy methods to get info out of pkgdb, FAS, and Koji on IRC). I can count the number of users of these packages on one hand (I would say one finger, but I know Kevin uses at least supybot-fedora ;) )
Does this mean that they're not of high quality just because no one uses them? Of course not. Same thing for Michael's packages I'd assume. A three month wait to get stuff into stable just seems WAY too long. As Kevin has already said, delay !=stable.
Jon Stanley wrote:
On Mon, Mar 30, 2009 at 7:37 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
which is why I suggested the automatic push (unless the package exhibited problems and received negative karma) after 3 months. which is half the release cycle of the main distro.
I still don't think that's a good idea. I maintain a few niche packages (supybot-fedora and supybot-koji) which are semi-critical to Fedora infrastructure (provides very easy methods to get info out of pkgdb, FAS, and Koji on IRC).
and both were reviewed by me as soon as I could do it after the bugs were submitted ...
I can count the number of users of these packages on one hand (I would say one finger, but I know Kevin uses at least supybot-fedora ;) )
persuade those < 5 users to give positive feedback via bodhi :) You should already know all of them personally :)
Does this mean that they're not of high quality just because no one uses them? Of course not.
of course not
Same thing for Michael's packages I'd assume. A three month wait to get stuff into stable just seems WAY too long. As Kevin has already said, delay !=stable.
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 ?
On Tue, Mar 31, 2009 at 2:58 AM, Manuel Wolfshant wolfy@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?
epel-devel@lists.fedoraproject.org