http://fedoraproject.org/wiki/EPEL/Reports/Week37
(/me still suffered from a cold/has a headache - I hope I didn't do even more typos then I usually do already when I wrote the report due to that...)
= Weekly EPEL Summary =
Week 37/2007
== Most important happenings ==
* push scripts improved (see below)
== EPEL SIG Meeting ==
=== Attending ===
* dgilmore (DennisGilmore) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * Jeff_S (Jeff Sheltren) * nirik (KevinFenzi) * stahnma (MichaelStahnke) * f13 (Jesse Keating) * warren (Warren Togami)
=== Summary ===
* pushing
* dglimore, nirik and mschwendt further improved and simplified pushing directly to stable and moving a package from testing to stable; thx guys, especially mschwendt!
* nirik will test them
* repo layout
* the plan written at http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-a98bce5283ee33... was to have directories for each release (e.g. have 5.0 as main repo now and a symlink from 5 pointing to it; when 5.1 ships run "cp -al 5.0 5.1" and adjust the "5" link to point to 5.1 instead; some weeks or months later remove the 5.0 dir to save the space; 5.0 btw would not be maintained anymore, we just leave it around for some weeks/months). This would allow people still on EL5.0 (for example those using derivates that do not ship 5.1 some weeks after RH does) to use EPEL5.0 without running into dependency issues that might arise when a package from EPEL5.1 depends on something from EL5.1;
* seems lots of people forgot about that plan never realized it full effects; do we still want that stuff? or in a modified way maybe?
* RHEL 5.1
* will likely be out soon; we don't know exactly when; thus the estimated EPEL testing -> stable move that is pushed in parallel will likely be a week (or two?) after EL 5.1 is out
* do more on the list and less in the meetings; "Power to the people with no delay." aka "Steering Committee's are slow and old style" -- all
* some discussion how to exactly do this; more discussions to follow the list
* RH relations
* warren: BTW, I inserted this rule into RH's processes for adding a new package to RHEL. Something like "Check EPEL to be sure your new package is newer"
* Free discussion around EPEL
* sticking with the alternate meeting time? we try another two or three weeks and decide afterwards
=== Full Log ===
https://www.redhat.com/archives/epel-devel-list/2007-September/msg00006.html
== Stats ==
=== General ===
Number of EPEL Contributors 6
We welcome 6 new contributors: candyz joshuadf lkundrak ondrejj salimma sundaram
=== EPEL 5 ===
Number of source packages: 655
Number of binary packages: 1261
There are 18 new Packages:
* abcde | A Better CD Encoder * aspell-sk | Slovak dictionaries for Aspell * cd-discid | Utility to get CDDB discid information * cvs2cl | Generate ChangeLogs from CVS working copies * dbench | Filesystem load benchmarking tool * directfb | Graphics abstraction library for the Linux Framebuffer Device * gcin | Input method for Traditional Chinese * gtk-qt-engine | A project allowing GTK to use Qt widget styles. * isync | Tool to synchronize IMAP4 and Maildir mailboxes * kasablanca | Graphical FTP client * lyx | WYSIWYM (What You See Is What You Mean) document processor * mach | Make a chroot * python-GnuPGInterface | A Python module to interface with GnuPG * pyzor | Pyzor collaborative spam filtering system * rubygem-rake | Ruby based make-like utility * rubygems | The Ruby standard for packaging ruby libraries * svn2cl | Create a ChangeLog from a Subversion log * tomcat-native | Tomcat native library
=== EPEL 4 ===
Number of source packages: 418
Number of binary packages: 850
There are 3 new Packages:
* isync | Tool to synchronize IMAP4 and Maildir mailboxes * python-GnuPGInterface | A Python module to interface with GnuPG * pyzor | Pyzor collaborative spam filtering system
---- ["CategoryEPELReports"]
On Mon, 17 Sep 2007 20:00:26 +0200 fedora@leemhuis.info (Thorsten Leemhuis) wrote:
... snip...
repo layout
the plan written at
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-a98bce5283ee33... was to have directories for each release (e.g. have 5.0 as main repo now and a symlink from 5 pointing to it; when 5.1 ships run "cp -al 5.0 5.1" and adjust the "5" link to point to 5.1 instead; some weeks or months later remove the 5.0 dir to save the space; 5.0 btw would not be maintained anymore, we just leave it around for some weeks/months). This would allow people still on EL5.0 (for example those using derivates that do not ship 5.1 some weeks after RH does) to use EPEL5.0 without running into dependency issues that might arise when a package from EPEL5.1 depends on something from EL5.1;
- seems lots of people forgot about that plan never realized it
full effects; do we still want that stuff? or in a modified way maybe?
yeah, I didn't realize that was the full plan. Not sure why I didn't see that before.
My concern with this is that the older repo will not be getting security updates, and that people will be depending on it not realizing it will go away. Not sure giving them a few weeks would assist any. People who don't want to update probibly won't update in a few weeks if there is no reason for them to do so.
I propose the following instead.
When 5.1 is released:
- mv 5.0 to 5.1 - link 5 and 5.0 to 5.1
This does mean that if there is something in 5.1 thats a new dependency, 5.0 users will need to upgrade or not use that package. However, it means that security/big bugfixes will keep going in that repo, and that if there are no new dependencies, folks running 5.0 can keep using the repo.
I don't think we have the manpower to maintain repos for each minor release. Also, aren't minor releases supposed to be ABI compatible?
RHEL 5.1
- will likely be out soon; we don't know exactly when; thus the
estimated EPEL testing -> stable move that is pushed in parallel will likely be a week (or two?) after EL 5.1 is out
Do we want to try and push new stable packages out to the repo before 5.1 at some point here? I know we talked about doing monthly pushes of stable new packages from testing->stable.
Also, I would really like to see the testing repo free of dependency issues before 5.1 is out. That would allow us to push everything in there into stable without problem.
kevin
On 9/18/07, Kevin Fenzi kevin@tummy.com wrote:
On Mon, 17 Sep 2007 20:00:26 +0200 fedora@leemhuis.info (Thorsten Leemhuis) wrote:
... snip...
repo layout
the plan written at
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-a98bce5283ee33... was to have directories for each release (e.g. have 5.0 as main repo now and a symlink from 5 pointing to it; when 5.1 ships run "cp -al 5.0 5.1" and adjust the "5" link to point to 5.1 instead; some weeks or months later remove the 5.0 dir to save the space; 5.0 btw would not be maintained anymore, we just leave it around for some weeks/months). This would allow people still on EL5.0 (for example those using derivates that do not ship 5.1 some weeks after RH does) to use EPEL5.0 without running into dependency issues that might arise when a package from EPEL5.1 depends on something from EL5.1;
- seems lots of people forgot about that plan never realized it
full effects; do we still want that stuff? or in a modified way maybe?
yeah, I didn't realize that was the full plan. Not sure why I didn't see that before.
My concern with this is that the older repo will not be getting security updates, and that people will be depending on it not realizing it will go away. Not sure giving them a few weeks would assist any. People who don't want to update probibly won't update in a few weeks if there is no reason for them to do so.
I propose the following instead.
When 5.1 is released:
- mv 5.0 to 5.1
- link 5 and 5.0 to 5.1
This does mean that if there is something in 5.1 thats a new dependency, 5.0 users will need to upgrade or not use that package. However, it means that security/big bugfixes will keep going in that repo, and that if there are no new dependencies, folks running 5.0 can keep using the repo.
I don't think we have the manpower to maintain repos for each minor release. Also, aren't minor releases supposed to be ABI compatible?
I completely agree. We don't have the manpower, or maintainer power to do this any other way. (And yes they should be ABI compatible).
RHEL 5.1
- will likely be out soon; we don't know exactly when; thus the
estimated EPEL testing -> stable move that is pushed in parallel will likely be a week (or two?) after EL 5.1 is out
Do we want to try and push new stable packages out to the repo before 5.1 at some point here? I know we talked about doing monthly pushes of stable new packages from testing->stable.
Also, I would really like to see the testing repo free of dependency issues before 5.1 is out. That would allow us to push everything in there into stable without problem.
kevin
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
epel-devel@lists.fedoraproject.org
-
Kevin Fenzi -
Michael Stahnke -
Thorsten Leemhuis