On Tue, 19 Jun 2007 14:45:52 +0200
fedora(a)leemhuis.info (Thorsten Leemhuis) wrote:
Hi,
seems we need koji modification to use bodhi, which likely itself
might need some adjustments for proper EPEL support as well. Both
things will take time to get realized as it seems other work is
higher on peoples todo list atm.
Yeah.
So I'd say EPEL should for the near future plan to continue to
use
plague together with the old Fedora Extras push scripts until we can
switch to koji and bodhi; otherwise it might take a long time until we
are ready to announce EPEL officially, which I'd like to avoid
See Mike's email on this. The push scripts currently don't have any way
to handle testing. So should we go forward without testing? Or try and
find some way to get them working with it?
We just should make sure the repo layout is sane for the near future
and can be used with bodihi later as well (Luke, that's why you are
in the CC of this mail; if there is anything that would be hard to
realize in bodihi let us know please).
I'd like to propose round about this layout below
http://redhat.download.fedoraproject.org/pub/epel/
stable/
4/ -> 4.(current_version())
4.1/
...
4.5/
5/ -> 5.(current_version())
5.1/
...
testing/
4/
5/
rolling/
4/ -> 4.(current_version())
4.1/
...
5/ -> 5.(current_version())
5.1/
...
We currently have symbolic links from "4{AS,WS,ES}" to "4" and
"5{Client,Server}" to "5" on the server as well; they should be
there
in the future as well, but I left them out of this scheme to not make
things even more complicated to understand.
Please ignore the "rolling" stuff as well; it seems some people would
like to have a more "Fedora Extras" like EPEL with a bold update
policy (always latest and greatest). I'd like to leave the path for
this open in the long term, that why I'd say we should put the
current EPEL stuff below "stable".
I think this adds to confusion... I thought we had determined that EPEL
was going to target more 'stable' type update methods?
Folks wanting a really fast a furious update should use another repo
that does that, or perhaps they could always have updates-testing
enabled (although that might not be fast enough for them).
How to realize the layout: have two different plague-targets per
release; the default target is "testing/(release())"; that repo
becomes the stable release automatically when RH ships a new
quarterly update. If you want to get something into the stable repo
for the current release use a special build target, from which the
extras-push-scripts push into the proper dir directly.
Humm... that might work. I don't know enough of how the push scripts
work currently. perhaps Dgilmore could comment?
Comments?
All sounds good except I would skip the 'stable/rolling' dirs.
CU
thl
kevin