There's been a lot of conversations about the testing -> stable process on this list, on IRC and just in general chats. Can someone explain what the current consensus is? I have branding concerns.
-Mike
On 26.08.2007 17:35, Mike McGrath wrote:
There's been a lot of conversations about the testing -> stable process on this list, on IRC and just in general chats. Can someone explain what the current consensus is? I have branding concerns.
Well, nothing new got decided yet. So the current plan is still the old:
- all new and updated packages go to testing - security updates go straight to stable or to testing for 24h and then get moved to stable - when a RHEL quarterly update is due we do what we did when we announced EPEL; e.g. make sure all deps are fulfilled in the repo (testing in this case) and expect the packages are working and move the packages to a new dir (e.g. 5.1/) and create a symlink from 5 -> 5.1 (thus people staying on 5.0 can stick to EPEL 5.0 if they want); cycle starts anew here and testing will get build for 5.2
What is under discussion is afaics this ( points with * are my option on the issue):
- move new packages to current stable more often
* I'd say that should be fine if they were in testing for some time (four weeks maybe?). But who is willing to do that work? Someone would need to prepare a repo locally, move all packages that fall under this rule over and make sure all deps are still satisfied in the porper repo. Then hand the list of to-be-moved-to-stable packages to one of the signers and let him move it over (when we have the proper tools in place, which is in the works; thx to mschwendt).
- move updated packages to stable more often
* if there is a strong need to move a package it is allowed according to the policy. But for the other updates I think we manage EPEL similar to how RHEL does it: non-crucial updates go into a quarterly update and no major updates if there isn't a reasons for them. Just "latest and greatest" is IMHO not the reason
- manage EPEL more like Fedora {,Extras}
* afaics most people in the buildup phase wanted a stable EPEL and I really think that should continue to be our #1 goal. But I see a need and interest for a "more up2date packages" EPEL repo. That what I call EPEL-rolling; I'm fine with having it in parallel to the stable repo. But do we have the man-power to start this yet?
CU thl
Thorsten Leemhuis wrote:
On 26.08.2007 17:35, Mike McGrath wrote:
There's been a lot of conversations about the testing -> stable process on this list, on IRC and just in general chats. Can someone explain what the current consensus is? I have branding concerns.
I'd really like to see something that is more updated than stable without being "testing". An additional level seems sufficient.
- if there is a strong need to move a package it is allowed according
to the policy. But for the other updates I think we manage EPEL similar to how RHEL does it: non-crucial updates go into a quarterly update and no major updates if there isn't a reasons for them. Just "latest and greatest" is IMHO not the reason
How do you determine which bugfixes are "serious enough"? ... it seems like the package maintainers usually would be the best qualified to make this decision if there is a bit of a guideline for it.
- manage EPEL more like Fedora {,Extras}
- afaics most people in the buildup phase wanted a stable EPEL and I
really think that should continue to be our #1 goal.
Are there threads that say this? The list membership isn't huge, and we probably have a lot of users that haven't joined ... I would think there is a sizeable community of users that just want a easy way to add useful and reasonably-working-well-together packages to their platform, so they can get their jobs done. What people want in leaf packages is probably not the same as what they want for core packages.
Quarterly doesn't really mean "stable", it just means "quarterly". So having a rolling stable where a package must be in testing for X seems reasonable to me. If we need an additional quarterly level that's ok, but if folks have to adopt everything from testing to just get one package from testing that is essentially considered stable that's a problem. I'd like to at least see an option where updates can be moved at some X which is much less than 120 days -- 2 weeks seems fair to me as most packages should have some adopters out of each repo.
But I see a need and interest for a "more up2date packages" EPEL repo. That what I call EPEL-rolling; I'm fine with having it in parallel to the stable repo. But do we have the man-power to start this yet?
Disregarding resources, what would we really like to do? I'd hate to shoot down an idea for how we are going to do things because there aren't resources. If it's a good enough idea, there might be resources crawling out of the woodwork ... you never know...
CU thl
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On 28.08.2007 20:32, Michael DeHaan wrote:
Thorsten Leemhuis wrote:
On 26.08.2007 17:35, Mike McGrath wrote:
- if there is a strong need to move a package it is allowed according
to the policy. But for the other updates I think we manage EPEL similar to how RHEL does it: non-crucial updates go into a quarterly update and no major updates if there isn't a reasons for them. Just "latest and greatest" is IMHO not the reason
How do you determine which bugfixes are "serious enough"? ... it seems like the package maintainers usually would be the best qualified to make this decision
Of course they are.
if there is a bit of a guideline for it.
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
Section "Some examples of what package updates that are fine or not"
- manage EPEL more like Fedora {,Extras}
- afaics most people in the buildup phase wanted a stable EPEL and I
really think that should continue to be our #1 goal.
Are there threads that say this?
Sorry, EPEL is being discussed for over a year now (first in private), and I can't point out a single thread -- but that my interpretation (it was in a * section, which were explicitly marked as my opinion) of lots of discussions that happend over the last year and lead to the guidelines as they were written.
[...] Quarterly doesn't really mean "stable", it just means "quarterly". So having a rolling stable where a package must be in testing for X seems reasonable to me.
Note that the idea was to freeze EPEL for some (two) weeks before pushing it to stable. We didn't do that, but I still think we should go for that in the long-term.
But I see a need and interest for a "more up2date packages" EPEL repo. That what I call EPEL-rolling; I'm fine with having it in parallel to the stable repo. But do we have the man-power to start this yet?
Disregarding resources, what would we really like to do? I'd hate to shoot down an idea for how we are going to do things because there aren't resources. If it's a good enough idea, there might be resources crawling out of the woodwork ... you never know...
On the other hand you can easily fail if you try to many things at once. And we have lots to improve in EPEL before doing the next big steps. Koji and Bodhi for EPEL. More packages. make sure we have a common look and feel (e.g. not "latest and greatest" in one area and "old and boring" in another one).
CU knurd
I'm still in favor of pushing more often during the initial build-up phase. I don't know exactly what that takes from the infrastructure team though. Right now, if a package is missing completely from EPEL, I would like it in stable (assuming it works and whatnot).
We probably do need some form of test-bed. Automated tests would be awesome. Sadly, writing test suites for thousands of packages probably isn't going to happen anytime soon.
The dependencies are a major concern. My hat is off to the guys thus far who have been rather successful with keeping EPEL working.
Is it possible to push new packages into stable? Even if something is in testing, just because it sat there for X amount of time, does it mean it works properly?
stahnma
epel-devel@lists.fedoraproject.org
-
Michael DeHaan -
Michael Stahnke -
Mike McGrath -
Thorsten Leemhuis