Hi,
in the past few months there were quite a few packages in EPEL which got version updates. This has come to a point where I seriously doubt my understanding of the EPEL policy.
Rahul Sundaram wrote [1]: "The simple rule: Don't release an update unless absolutely necessary. This is to avoid regressions."
This was exactly my understanding of how package updates should be done in EPEL.
But obviously other packagers don't see this policy so strictly - or maybe I'm just too blind to find important information why all these updates were absolutely necessary.
One example is shorewall which had several updates in the last months, always to match the latest upstream version: http://cvs.fedoraproject.org/viewcvs/rpms/shorewall/EL-5/shorewall.spec?rev=... Thankfully, no update caused trouble for me but I'm a bit sceptical if this update policy is really healthy for EPEL.
There are other packages, too. I don't want to list every packages and some updates are really nice. But let's take python-genshi 0.5 which is currently in testing for EPEL 5 and about to be pushed shortly: http://cvs.fedoraproject.org/viewcvs/rpms/python-genshi/EL-5/python-genshi.s...
0.5 changed some semantics of py:match and I personally had troubles when upgrading from 0.4.4 to 0.5. So while most people won't experience any problems, this is one of the upgrades that can cause pain.
Some other examples: http://cvs.fedoraproject.org/viewcvs/rpms/python-lxml/EL-5/python-lxml.spec http://cvs.fedoraproject.org/viewcvs/rpms/python-paste/EL-5/python-paste.spe...
I understand that there are packages like Firefox, Wine and clamav which must be always at the latest version because it makes no sense/its impossible to backport all the important stuff. But what I don't understand is why all these library packages are updated so often.
IMHO EPEL should have more control over updates so that every package update gets a solid reasoning why the package has to updated, if there are known compatibility issues and so on...
I always thought of EPEL as 'this is an repository where I can pull updates without too much caution because the guys will really make sure that every package is necessary'. </rant>
fs
[1] https://www.redhat.com/archives/epel-devel-list/2008-April/msg00019.html
Felix Schwarz wrote:
Hi,
in the past few months there were quite a few packages in EPEL which got version updates. This has come to a point where I seriously doubt my understanding of the EPEL policy.
Rahul Sundaram wrote [1]: "The simple rule: Don't release an update unless absolutely necessary. This is to avoid regressions."
This was exactly my understanding of how package updates should be done in EPEL.
But obviously other packagers don't see this policy so strictly - or maybe I'm just too blind to find important information why all these updates were absolutely necessary.
One example is shorewall which had several updates in the last months, always to match the latest upstream version: http://cvs.fedoraproject.org/viewcvs/rpms/shorewall/EL-5/shorewall.spec?rev=...
Thankfully, no update caused trouble for me but I'm a bit sceptical if this update policy is really healthy for EPEL.
There are other packages, too. I don't want to list every packages and some updates are really nice. But let's take python-genshi 0.5 which is currently in testing for EPEL 5 and about to be pushed shortly: http://cvs.fedoraproject.org/viewcvs/rpms/python-genshi/EL-5/python-genshi.s...
0.5 changed some semantics of py:match and I personally had troubles when upgrading from 0.4.4 to 0.5. So while most people won't experience any problems, this is one of the upgrades that can cause pain.
Some other examples: http://cvs.fedoraproject.org/viewcvs/rpms/python-lxml/EL-5/python-lxml.spec http://cvs.fedoraproject.org/viewcvs/rpms/python-paste/EL-5/python-paste.spe...
I understand that there are packages like Firefox, Wine and clamav which must be always at the latest version because it makes no sense/its impossible to backport all the important stuff. But what I don't understand is why all these library packages are updated so often.
IMHO EPEL should have more control over updates so that every package update gets a solid reasoning why the package has to updated, if there are known compatibility issues and so on...
I always thought of EPEL as 'this is an repository where I can pull updates without too much caution because the guys will really make sure that every package is necessary'.
</rant>
fs
[1] https://www.redhat.com/archives/epel-devel-list/2008-April/msg00019.html
Agree 100%. I tend to take the same approach on stable Fedora releases too, but it's even more important to do so in EPEL.
Paul.
On 01.07.2008 10:32, Paul Howarth wrote:
Felix Schwarz wrote:
in the past few months there were quite a few packages in EPEL which got version updates. This has come to a point where I seriously doubt my understanding of the EPEL policy.
Rahul Sundaram wrote [1]: "The simple rule: Don't release an update unless absolutely necessary. This is to avoid regressions."
This was exactly my understanding of how package updates should be done in EPEL.
But obviously other packagers don't see this policy so strictly - or maybe I'm just too blind to find important information why all these updates were absolutely necessary.
[examples striped]
I understand that there are packages like Firefox, Wine and clamav which must be always at the latest version because it makes no sense/its impossible to backport all the important stuff. But what I don't understand is why all these library packages are updated so often.
IMHO EPEL should have more control over updates so that every package update gets a solid reasoning why the package has to updated, if there are known compatibility issues and so on...
I always thought of EPEL as 'this is an repository where I can pull updates without too much caution because the guys will really make sure that every package is necessary'.
</rant> [1] https://www.redhat.com/archives/epel-devel-list/2008-April/msg00019.html
Agree 100%. I tend to take the same approach on stable Fedora releases too, but it's even more important to do so in EPEL.
I don't have time to discuss the details right now, but I tend to agree.
Some suggestions how to fix this:
- do the general testing -> stable moves less often (every three or four months maybe?); that was in the initial EPEL plans (but was changed later on) and will indirectly force maintainers to slow down a bit (but that doesn't solve the problem completely; further: new packages IMHO should be moved more often)
- educate EPEL contributors; e.g. let someone watch the CVS commits to EL branches closely; if there is a big update ask the maintainer why that is needed (I did that in the past now and then when I was EPEL chair, but I don't have time for it anymore; sorry); if unneeded remove the build before it gets pushed to testing
CU knurd
Thorsten Leemhuis wrote:
On 01.07.2008 10:32, Paul Howarth wrote:
Felix Schwarz wrote:
in the past few months there were quite a few packages in EPEL which got version updates. This has come to a point where I seriously doubt my understanding of the EPEL policy.
Rahul Sundaram wrote [1]: "The simple rule: Don't release an update unless absolutely necessary. This is to avoid regressions."
This was exactly my understanding of how package updates should be done in EPEL.
But obviously other packagers don't see this policy so strictly - or maybe I'm just too blind to find important information why all these updates were absolutely necessary.
[examples striped]
I understand that there are packages like Firefox, Wine and clamav which must be always at the latest version because it makes no sense/its impossible to backport all the important stuff. But what I don't understand is why all these library packages are updated so often.
IMHO EPEL should have more control over updates so that every package update gets a solid reasoning why the package has to updated, if there are known compatibility issues and so on...
I always thought of EPEL as 'this is an repository where I can pull updates without too much caution because the guys will really make sure that every package is necessary'.
</rant> [1] https://www.redhat.com/archives/epel-devel-list/2008-April/msg00019.html
Agree 100%. I tend to take the same approach on stable Fedora releases too, but it's even more important to do so in EPEL.
I don't have time to discuss the details right now, but I tend to agree.
So do I. But with a grain of salt
Some suggestions how to fix this:
- do the general testing -> stable moves less often (every three or
four months maybe?); that was in the initial EPEL plans (but was changed later on) and will indirectly force maintainers to slow down a bit (but that doesn't solve the problem completely; further: new packages IMHO should be moved more often)
We could follow the RH pace, but I really really do not like it.
- educate EPEL contributors; e.g. let someone watch the CVS commits to
EL branches closely; if there is a big update ask the maintainer why that is needed (I did that in the past now and then when I was EPEL chair, but I don't have time for it anymore; sorry); if unneeded remove the build before it gets pushed to testing
I agree 100% here. Education is the key.
On Tue, Jul 01, 2008 at 11:06:16AM +0200, Thorsten Leemhuis wrote:
On 01.07.2008 10:32, Paul Howarth wrote:
Felix Schwarz wrote:
in the past few months there were quite a few packages in EPEL which got version updates. This has come to a point where I seriously doubt my understanding of the EPEL policy.
Rahul Sundaram wrote [1]: "The simple rule: Don't release an update unless absolutely necessary. This is to avoid regressions."
This was exactly my understanding of how package updates should be done in EPEL.
But obviously other packagers don't see this policy so strictly - or maybe I'm just too blind to find important information why all these updates were absolutely necessary.
I understand that there are packages like Firefox, Wine and clamav which must be always at the latest version because it makes no sense/its impossible to backport all the important stuff. But what I don't understand is why all these library packages are updated so often.
IMHO EPEL should have more control over updates so that every package update gets a solid reasoning why the package has to updated, if there are known compatibility issues and so on...
I always thought of EPEL as 'this is an repository where I can pull updates without too much caution because the guys will really make sure that every package is necessary'. </rant> [1] https://www.redhat.com/archives/epel-devel-list/2008-April/msg00019.html
Agree 100%. I tend to take the same approach on stable Fedora releases too, but it's even more important to do so in EPEL.
I would love to see there be a place for some elasticity. And it'll end up being pretty arbitrary to enforce I imagine. Not all of us have the technical ability or time to backport fixes and so the risk of regression is always going to be higher than it would with a normal RHEL package.
I don't have time to discuss the details right now, but I tend to agree.
Some suggestions how to fix this:
- do the general testing -> stable moves less often (every three or
four months maybe?); that was in the initial EPEL plans (but was changed later on) and will indirectly force maintainers to slow down a bit (but that doesn't solve the problem completely; further: new packages IMHO should be moved more often)
- educate EPEL contributors; e.g. let someone watch the CVS commits
to EL branches closely; if there is a big update ask the maintainer why that is needed (I did that in the past now and then when I was EPEL chair, but I don't have time for it anymore; sorry); if unneeded remove the build before it gets pushed to testing
This would definitely be a necessary step, and probably not a fun job. Lots of people simply push new updates to their packages when upstream releases it... and by and large it's been harmless but certainly doesn't fit in with EPEL's goals...
I'm somewhat torn though. It's one thing to not update something that provides an API to other programs, but maybe less of an issue to update a client only program -- something like freehoo (CLI Yahoo messenger client) which is something I would hate to see stuck at a really old version just because it's against policy to update it.
Is there a place for a -unstable branch for those of us who want to have updated / newer packages?
I just want to avoid a situation where I end up either maintaining a personal repository of "newer" packages for EL-5 simply because I'm stuck at an old version in EPEL, or end up deciding to maintain a new package in a repository with less restrictive rules....
Take with a grain of salt; this is coming from a guy who only maintains a few packages for personal and work use.
Ray
Ray Van Dolson wrote:
I'm somewhat torn though. It's one thing to not update something that provides an API to other programs, but maybe less of an issue to update a client only program -- something like freehoo (CLI Yahoo messenger client) which is something I would hate to see stuck at a really old version just because it's against policy to update it.
I think there's a good case for a distinction between "top-level" packages (like freehoo) and those that other packages depend on as you say. And there's precedent for that in RHEL too, given that RHEL 5.2 has a firefox 3 beta for instance.
Paul.
On Tue, Jul 01, 2008 at 02:54:36PM +0100, Paul Howarth wrote:
Ray Van Dolson wrote:
I'm somewhat torn though. It's one thing to not update something that provides an API to other programs, but maybe less of an issue to update a client only program -- something like freehoo (CLI Yahoo messenger client) which is something I would hate to see stuck at a really old version just because it's against policy to update it.
I think there's a good case for a distinction between "top-level" packages (like freehoo) and those that other packages depend on as you say. And there's precedent for that in RHEL too, given that RHEL 5.2 has a firefox 3 beta for instance.
Well put, Paul. Packages that mostly run standalone are appropriate candidates for a rebase (like freehoo and firefox), but those that serve as libraries or building blocks for other components should try to stay as stable as possible from an ABI/API perspective.
I would like to think we can make this as open as possible (no rules yet) and defer to the judgment of individual package maintainers when deciding whether a rebase or backport is the way to go. Generally those closest to the code know which change is best -- they will just need to be prepared with an answer that is better than, "I was too lazy to backport" if they cause a lot of problems for users when rebasing.
-andy
Andy Gospodarek schrieb:
Well put, Paul. Packages that mostly run standalone are appropriate candidates for a rebase (like freehoo and firefox), but those that serve as libraries or building blocks for other components should try to stay as stable as possible from an ABI/API perspective.
I would like to add the distinction between "server" and "desktop" software. While both categories are not always disjoint, it this the distinction is useful nevertheless: Some things like Firefox, OpenOffice etc. can be updated more often than something like Exim, Apache, ...
This is a bit like Red Hat does it these days.
fs
On Tue, Jul 01, 2008 at 05:46:15PM +0200, Felix Schwarz wrote:
Andy Gospodarek schrieb:
Well put, Paul. Packages that mostly run standalone are appropriate candidates for a rebase (like freehoo and firefox), but those that serve as libraries or building blocks for other components should try to stay as stable as possible from an ABI/API perspective.
I would like to add the distinction between "server" and "desktop" software. While both categories are not always disjoint, it this the distinction is useful nevertheless: Some things like Firefox, OpenOffice etc. can be updated more often than something like Exim, Apache, ...
That is an excellent point. Should we consider breaking EPEL into an EPEL-Base and EPEL-Desktop? If we had separate repos it might be helpful.
I would be in favor of that and then possibly change the way we queue something to move from testing to stable so that it can remain in testing longer.
On Tue, Jul 01, 2008 at 12:25:10PM -0400, Andy Gospodarek wrote:
On Tue, Jul 01, 2008 at 05:46:15PM +0200, Felix Schwarz wrote:
Andy Gospodarek schrieb:
Well put, Paul. Packages that mostly run standalone are appropriate candidates for a rebase (like freehoo and firefox), but those that serve as libraries or building blocks for other components should try to stay as stable as possible from an ABI/API perspective.
I would like to add the distinction between "server" and "desktop" software. While both categories are not always disjoint, it this the distinction is useful nevertheless: Some things like Firefox, OpenOffice etc. can be updated more often than something like Exim, Apache, ...
That is an excellent point. Should we consider breaking EPEL into an EPEL-Base and EPEL-Desktop? If we had separate repos it might be helpful.
I would be in favor of that and then possibly change the way we queue something to move from testing to stable so that it can remain in testing longer.
Would the same package exist potentially in either repository? I'm just trying to think how this might effect CentOS users who don't have the concept of Desktop/Server...
I kind of like the -unstable option myself...
Ray
On Tue, Jul 01, 2008 at 09:33:08AM -0700, Ray Van Dolson wrote:
On Tue, Jul 01, 2008 at 12:25:10PM -0400, Andy Gospodarek wrote:
On Tue, Jul 01, 2008 at 05:46:15PM +0200, Felix Schwarz wrote:
Andy Gospodarek schrieb:
Well put, Paul. Packages that mostly run standalone are appropriate candidates for a rebase (like freehoo and firefox), but those that serve as libraries or building blocks for other components should try to stay as stable as possible from an ABI/API perspective.
I would like to add the distinction between "server" and "desktop" software. While both categories are not always disjoint, it this the distinction is useful nevertheless: Some things like Firefox, OpenOffice etc. can be updated more often than something like Exim, Apache, ...
That is an excellent point. Should we consider breaking EPEL into an EPEL-Base and EPEL-Desktop? If we had separate repos it might be helpful.
I would be in favor of that and then possibly change the way we queue something to move from testing to stable so that it can remain in testing longer.
Would the same package exist potentially in either repository? I'm just trying to think how this might effect CentOS users who don't have the concept of Desktop/Server...
Good question. I would think that EPEL-Desktop would be everything and EPEL-Base would be just the components that we deem important enough to not take huge backports each time. Basically Base would be a subset of Desktop.
On Tue, 1 Jul 2008 12:25:10 -0400, Andy Gospodarek wrote:
I would like to add the distinction between "server" and "desktop" software. While both categories are not always disjoint, it this the distinction is useful nevertheless: Some things like Firefox, OpenOffice etc. can be updated more often than something like Exim, Apache, ...
That is an excellent point. Should we consider breaking EPEL into an EPEL-Base and EPEL-Desktop? If we had separate repos it might be helpful.
Danger lies ahead. This feels like the old Fedora Extras with Core as the base, where you are stuck if you need base packages newer than what Core offers. With it comes the desire to upgrade base. And for EPEL that would mean to upgrade RHEL.
I think RHEL/EPEL/CentOS users should accept that they cannot get the latest on top of a stable [several years old] base.
Michael Schwendt schrieb:
On Tue, 1 Jul 2008 12:25:10 -0400, Andy Gospodarek wrote:
That is an excellent point. Should we consider breaking EPEL into an EPEL-Base and EPEL-Desktop? If we had separate repos it might be helpful.
Danger lies ahead. This feels like the old Fedora Extras with Core as the base, where you are stuck if you need base packages newer than what Core offers. With it comes the desire to upgrade base. And for EPEL that would mean to upgrade RHEL.
I think RHEL/EPEL/CentOS users should accept that they cannot get the latest on top of a stable [several years old] base.
I think we should not split EPEL. One repo is good (because the separation line between desktop and server is blurry, it will cause more work load for all packagers, potentially dependency problems etc)., but maybe an unstable branch is ok (so you can get some few selected packages which you like to get updated). That would essentially mirror the Debian testing system.
This topic will occur more often I think when more people start using CentOS/RHEL on the desktop.
But essentially EPEL should be (IMHO) about stability and reliability! What I would like to see is that every update needs a short reasoning why the package should be updated and that someone else can read the description and approve the update (or reject it).
Its just that I'm somewhat more relaxed when "desktop" software should be updated.
fs
Hi Ray,
first of all, I do appreciate your concerns: My free time is very limited too and I'm doing most of my (very few!) package activities in my free time. But I think the raison d'être for EPEL is well packaged software which is nearly as good as RHEL packages (as good you can be with only volunteers).
Ray Van Dolson schrieb:
Is there a place for a -unstable branch for those of us who want to have updated / newer packages?
IMHO an unstable branch would be a quite good idea.
Just to share some other idea of mine which is only loosely related to the unstable EPEL thing: I have a slightly different problem when it comes to updated versions: E.g. I'm doing much TurboGears-related development so I like having the latest TurboGears and related components but the rest should be as stable as possible.
Other example: I'm compiling EL4/5 RPM packages for Bacula which are published on Bacula's SF page. Of course there are some admins out there who really want the new Bacula version - even on RHEL. Bacula in EPEL 5 is at 2.0 (and not even present in EPEL 4 - ixs: *hint* ;-). I thought about updating the high-quality EPEL RPMs for newer versions and to provide updated RPMs on a Fedora-associated (user) page.
So after all I think there is no 'one fits it all' solution but more something like an 'updated stack' which are just additional repositories.
fs
On Tue, Jul 1, 2008 at 1:23 AM, Felix Schwarz felix.schwarz@oss.schwarz.eu wrote:
Hi,
in the past few months there were quite a few packages in EPEL which got version updates. This has come to a point where I seriously doubt my understanding of the EPEL policy.
Rahul Sundaram wrote [1]: "The simple rule: Don't release an update unless absolutely necessary. This is to avoid regressions."
Ok the big problem is that there are multiple types of users for EPEL, and each group seems to wax and wane in asking for things. Several months ago, the people who wanted to have newer stuff regularly versus once a quarter asked and got enough push to get it done. Now we are approaching the other side and the people who want it once a quarter or never are asking for things... the problem is that the basic build system and controls are limited in scope of what can be accomplished. I would love to be able to have different channels for each of the types of releases that people want, but everyone wants something different.
In the end, we had few volunteers/packages and many more "we want X"'ers than we could handle when we did quarterly releases. We moved to a monthly schedule and we have more volunteers/packages and can handle more of the "We want X" people. However, this does not work well for various sites. How to solve this problem is really hard, and I am not sure anyone has come up with a solution that more than 1 or 2 other people want to try.
-- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"
Stephen John Smoogen schrieb:
Ok the big problem is that there are multiple types of users for EPEL, and each group seems to wax and wane in asking for things. Several months ago, the people who wanted to have newer stuff regularly versus once a quarter asked and got enough push to get it done.
I think you are right that there are different types of users. You can't make everyone happy.
But it is not (at least from my pov) about monthly vs. quarterly releases. I really like monthly updates. But the EPEL policy (as I read it) states that version updates should not happen unless there is a really good reason. IMHO the question whether to push new packages on a quarterly, monthly or daily basis is completely separate.
I would love to be able to have different channels for each of the types of releases that people want, but everyone wants something different.
That's why I think we should concentrate on the stable policy. If the infrastructure gets in a shape that we can serve an unstable branch (and we have the volunteers to do it!), we could extend EPEL's focus.
Felix Schwarz
On Tue, Jul 1, 2008 at 12:38 PM, Felix Schwarz felix.schwarz@oss.schwarz.eu wrote:
Stephen John Smoogen schrieb:
Ok the big problem is that there are multiple types of users for EPEL, and each group seems to wax and wane in asking for things. Several months ago, the people who wanted to have newer stuff regularly versus once a quarter asked and got enough push to get it done.
I think you are right that there are different types of users. You can't make everyone happy.
But it is not (at least from my pov) about monthly vs. quarterly releases. I really like monthly updates. But the EPEL policy (as I read it) states that version updates should not happen unless there is a really good reason. IMHO the question whether to push new packages on a quarterly, monthly or daily basis is completely separate.
I guess I need help parsing in what you are meaning by stable. are you meaning:
A) el5/nethack-3.4.3 should always be el5/nethack-3.4.3 with only patches to that version of the software?
B) that once a month it could be minorly updated say from el5/nethack-3.4.3 to el5/nethack-3.4.5 as long as the code base is mostly the same without major patches?
C) that once a month it could go like el5/nethack-3.4.3 to el5/nethack-4.0?
or something else?
I would love to be able to have different channels for each of the types of releases that people want, but everyone wants something different.
That's why I think we should concentrate on the stable policy. If the infrastructure gets in a shape that we can serve an unstable branch (and we have the volunteers to do it!), we could extend EPEL's focus.
The only time I have seen strong commitment to a stable branch is when things break... and then it is forgotten a month or two later.
Stephen John Smoogen schrieb:
I guess I need help parsing in what you are meaning by stable. are you meaning:
A) el5/nethack-3.4.3 should always be el5/nethack-3.4.3 with only patches to that version of the software?
A) with the exception that there can be 'good reasons' (like security fixes can not be backported, version update has huge benefits because XYZ) that a package should be updated. Especially because EPEL is driven by volunteers so we don't have the manpower to do too much backporting.
The only time I have seen strong commitment to a stable branch is when things break... and then it is forgotten a month or two later.
I guess you are right :-) But I know some packagers who don't bring their packages into EPEL yet because they want a version that is 'here to stay'. Therefore python-beaker is not yet in EPEL (probably the 1.0 version will). pyPdf was not updated too.
And the old version of python-zope-interface currently blocks 3-4 other packages of mine but I'm very hesitant to update that library so I guess I will wait until I can make sure that there will be no backwards compatibility problems.
fs
Felix Schwarz wrote:
Hi,
in the past few months there were quite a few packages in EPEL which got version updates. This has come to a point where I seriously doubt my understanding of the EPEL policy.
Rahul Sundaram wrote [1]: "The simple rule: Don't release an update unless absolutely necessary. This is to avoid regressions."
This was exactly my understanding of how package updates should be done in EPEL.
But obviously other packagers don't see this policy so strictly - or maybe I'm just too blind to find important information why all these updates were absolutely necessary.
I'd like to give my opinion on this. I've pretty much been a Red Hat user since MKLinux DR3 (based on RH 5.1) - RH 6.1 was my first i386 distribution.
Back then, Linux was just beginning to emerge, getting the latest software was always a bonus because it was leaps and bounds ahead of the rest.
I really liked Red Hat 8 once the first set of major bugs was fixed, but jumped on the Fedora bandwagon because there were still extremely exciting things happening with each new release.
Maybe part of it is because I'm older now than I was back then, but honestly, I'm not as gung ho about having the freshest releases of software as I use to be. In my opinion, OSS has matured to the point where as a *desktop user* I would rather have a slighly older release that is stable than a fresh release with new features and new bugs. For example, for whatever reasons - evolution in Fedora 8 was unusable to me, it had some cool new stuff but it had some major issues, particularly with my laptop, which was a slow low memory machine.
There are a few exceptions. I do think RHEL is justified in moving Firefox to FF3. The reason is twofold -
1) Firefox has a huge codebase. It would take extreme amount of man power to continue to maintain FF 1.x without upstream.
2) The web evolves quickly, and a browser must keep in touch with modern web innovations, particularly in the area of javascript and CSS implementation.
I think RHEL moving to modern Firefox was the right decision. For most other software though, my opinion - if you want to run the latest versions, use Fedora. That's not what RHEL/CentOS are for.
At this point - there is enough functionallity in desktop apps to have an extremely usable desktop system with apps that are not the latest and greatest. RHEL should provide a stable desktop without introducing the new bugs and new quirks that come with new software.
That's my 2 cents on the issue.
Michael A. Peters wrote:
There are a few exceptions. I do think RHEL is justified in moving Firefox to FF3. The reason is twofold -
- Firefox has a huge codebase. It would take extreme amount of man
power to continue to maintain FF 1.x without upstream.
- The web evolves quickly, and a browser must keep in touch with modern
web innovations, particularly in the area of javascript and CSS implementation.
A small addition here; RHEL does so by releasing a minor update to the entire operating system (5.2) - so everyone knows to look for changes like these. Is this something EPEL can do as well?
EPEL 5.1/nethack-3.4.3
EPEL 5.2/nethack-4.0 (for the right reasons)
Just a thought.
Kind regards,
Jeroen van Meeuwen -kanarip
On Wed, Jul 2, 2008 at 3:27 PM, Jeroen van Meeuwen kanarip@kanarip.com wrote:
Michael A. Peters wrote:
There are a few exceptions. I do think RHEL is justified in moving Firefox to FF3. The reason is twofold -
- Firefox has a huge codebase. It would take extreme amount of man power
to continue to maintain FF 1.x without upstream.
- The web evolves quickly, and a browser must keep in touch with modern
web innovations, particularly in the area of javascript and CSS implementation.
A small addition here; RHEL does so by releasing a minor update to the entire operating system (5.2) - so everyone knows to look for changes like these. Is this something EPEL can do as well?
EPEL 5.1/nethack-3.4.3
EPEL 5.2/nethack-4.0 (for the right reasons)
Just a thought.
I think that will imply to add another epel branch. such as move epel to EL-5.1 and then add EL-5.2
Kind regards,
Jeroen van Meeuwen -kanarip
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
Jeroen van Meeuwen wrote:
Michael A. Peters wrote:
There are a few exceptions. I do think RHEL is justified in moving Firefox to FF3. The reason is twofold -
- Firefox has a huge codebase. It would take extreme amount of man
power to continue to maintain FF 1.x without upstream.
- The web evolves quickly, and a browser must keep in touch with
modern web innovations, particularly in the area of javascript and CSS implementation.
A small addition here; RHEL does so by releasing a minor update to the entire operating system (5.2) - so everyone knows to look for changes like these. Is this something EPEL can do as well?
EPEL 5.1/nethack-3.4.3
EPEL 5.2/nethack-4.0 (for the right reasons)
Just a thought.
To be honest, I think it would be too much effort to keep separate branches of EPEL for each point release just for the few cases where there is a legitimate reason to update a package.
If a user doesn't want to upgrade to a point release, the user can add nethack to their excludes for automatic updates.
Michael A. Peters wrote:
Jeroen van Meeuwen wrote:
Michael A. Peters wrote:
There are a few exceptions. I do think RHEL is justified in moving Firefox to FF3. The reason is twofold -
- Firefox has a huge codebase. It would take extreme amount of man
power to continue to maintain FF 1.x without upstream.
- The web evolves quickly, and a browser must keep in touch with
modern web innovations, particularly in the area of javascript and CSS implementation.
A small addition here; RHEL does so by releasing a minor update to the entire operating system (5.2) - so everyone knows to look for changes like these. Is this something EPEL can do as well?
EPEL 5.1/nethack-3.4.3
EPEL 5.2/nethack-4.0 (for the right reasons)
Just a thought.
To be honest, I think it would be too much effort to keep separate branches of EPEL for each point release just for the few cases where there is a legitimate reason to update a package.
It doesn't need to be actual CVS / build branches, it could be done the way this-other-EL5-distribution does it.
It does mean keeping EPEL 5.1 RPM files around.
It may mean a maintainer can but doesn't need to update non-current-point-releases.
Like I said, it's just a thought. Something to ponder, if you will. This is how I anticipated EPEL would work back in Boston, February 2007. It has been disappointing to see that it doesn't, but who am I to say that not having been involved with setting it up and contributing to it's infrastructure.
Miguel Filho wrote:
That is exactly my point on another mail I sent to this list. A repository that don't follow the RHEL release is just a no go to me.
+1.
If there's anything that needs to happen to make it so, let me know and I'll know what I can do (and I'd like to think some others will have that too).
Kind regards,
Jeroen van Meeuwen -kanarip
On Wed, 2 Jul 2008, Michael A. Peters wrote:
Jeroen van Meeuwen wrote:
Michael A. Peters wrote:
There are a few exceptions. I do think RHEL is justified in moving Firefox to FF3. The reason is twofold -
- Firefox has a huge codebase. It would take extreme amount of man power
to continue to maintain FF 1.x without upstream.
- The web evolves quickly, and a browser must keep in touch with modern
web innovations, particularly in the area of javascript and CSS implementation.
A small addition here; RHEL does so by releasing a minor update to the entire operating system (5.2) - so everyone knows to look for changes like these. Is this something EPEL can do as well?
EPEL 5.1/nethack-3.4.3
EPEL 5.2/nethack-4.0 (for the right reasons)
Just a thought.
To be honest, I think it would be too much effort to keep separate branches of EPEL for each point release just for the few cases where there is a legitimate reason to update a package.
I generally agree. It'd be nice to have different branches and follow them. but I can't imagine what the world will be like with RHEL6 comes out, by then we could be maintaining 2 or 3 different RHEL4 branches, potentially 5 or 6 RHEL5 branches, then the RHEL6.0 branch.
For my use case anyway, EPEL's served quite well, I haven't had too many problems and the package updates are certainly less frequent then Fedora.
-Mike
I tend to agree with Mike and several of the previous comments in this thread.
EPEL was designed to supplement EL with packages not included in the base. It has been, and will continue to do this. If the package is updating too frequently, the solution is simple, don't update. (disable automatic yum, or up2date or whatever). Create a release strategy for your needs. The repository and upgrade strategy are not (and should not) be one in the same. If it's not updating often enough, you are welcome to uses other repos, or supplement with your own updates.
I tend to think that currently, the Fedora Project and contributors would not be able to sustain a quality-driven branch for unstable, or 5.1 vs 5.2 etc and so on. I still think that EPEL is much better than me having to hand pick every RPM from Fedora SRPMS and recompile them by hand, store them in my own repositories and then watch as incompatibilities crop up.
Keep in mind that EPEL's goal is to make high-quality, fedora approved, packages available. How you use them is up to you.
I also gave a talk on managing updates at the Red Hat Summit, if you want to check it out, please do so. http://stahnma.fedorapeople.org/summit/updates.odp
stahnma
After doing a lot of thinking at the vet this weekend, I just do not see how we have the man-power to meet a 'super'-stable release model. Super-stable requires a lot of effort to review and backport changes.. which is why many of us are paying 'Red Hat' or some consultant with CentOS/SciLin to do for us. I do not see how we can do so without a similar revenue stream to pay for people to sit and keep stuff from bit-rotting or forcing updates to newer versions because the code between 1.0.1 and 1.0.2 changed over 30%.
It is also hard to know what is 'stable' enough for some groups. For everyone who wants to keep rt3 at an old version there are those who want a newer version because it has the features they need. The only solutions I could see to this were:
a) giving people the tools to easily stick to what they want (in the way that Dag says for people wanting older stuff from him to use mrepo or similar to make their own local repository... not that many people do that... but those who were warned don't get much sympathy .)
b) make it possible to have multiple levels of support when the bodhi/plague system is implemented. What I was seeing is that we have say 4 channels: alpha -- stuff from Fedora is built just like anything else for EL-4,5,6 and is either 'blacklisted' or 'eats-babies' beta -- stuff voted as being good enough is put here (eg EPEL-testing). gamma -- stuff voted to here is good enough for production. delta -- the last item from gamma is moved here... people can keep track of old items via this. epsilon -- really stable releases are here.
the progression is then open to people and they can become involved by lobbying to keep something in gamma or moving it to delta.. elections would be held on a monthly system for items they wanted. of course this is all pie in the sky at the moment.. but worth looking at someday.
anyway, back to the vet.
On Wed, Jul 2, 2008 at 10:27 AM, Jeroen van Meeuwen kanarip@kanarip.com wrote:
A small addition here; RHEL does so by releasing a minor update to the entire operating system (5.2) - so everyone knows to look for changes like these. Is this something EPEL can do as well?
EPEL 5.1/nethack-3.4.3
EPEL 5.2/nethack-4.0 (for the right reasons)
That is exactly my point on another mail I sent to this list. A repository that don't follow the RHEL release is just a no go to me.
Regards,
Miguel
Miguel Filho wrote:
On Wed, Jul 2, 2008 at 10:27 AM, Jeroen van Meeuwen kanarip@kanarip.com wrote:
A small addition here; RHEL does so by releasing a minor update to the entire operating system (5.2) - so everyone knows to look for changes like these. Is this something EPEL can do as well?
EPEL 5.1/nethack-3.4.3
EPEL 5.2/nethack-4.0 (for the right reasons)
That is exactly my point on another mail I sent to this list. A repository that don't follow the RHEL release is just a no go to me.
Well since there isn't any third party reposiory following the EL release model, it makes sense to explain why you need such a model. Simply demanding that it should be done without providing a good explanation isn't really motivating anybody.
Rahul
Miguel Filho wrote:
On Wed, Jul 2, 2008 at 10:27 AM, Jeroen van Meeuwen kanarip@kanarip.com wrote:
A small addition here; RHEL does so by releasing a minor update to the entire operating system (5.2) - so everyone knows to look for changes like these. Is this something EPEL can do as well?
EPEL 5.1/nethack-3.4.3
EPEL 5.2/nethack-4.0 (for the right reasons)
That is exactly my point on another mail I sent to this list. A repository that don't follow the RHEL release is just a no go to me.
Well since there isn't any third party repository following the EL release model, it makes sense to explain why you need such a model. Simply demanding that it should be done without providing a good explanation isn't really motivating anybody.
Rahul
epel-devel@lists.fedoraproject.org
-
Andy Gospodarek -
Felix Schwarz -
Jeroen van Meeuwen -
Manuel Wolfshant -
Michael A. Peters -
Michael Schwendt -
Michael Stahnke -
Miguel Filho -
Mike McGrath -
Paul Howarth -
Rahul Sundaram -
Ray Van Dolson -
Stephen John Smoogen -
Thorsten Leemhuis -
Xavier Lamien