So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and thus triggering CentOS, and I imagine Oracle, Scientific et al).
What are the plans for EPEL 4?
The way I see we have a few options:
1. We stop putting new content in EPEL4 and take down the EPEL mirror (thus really end-of-lifeing EPEL 4) 2. We stop putting in new content, and leave the mirrors, thus allowing those who haven't migrated to ahve some sort of package options, with no option for updates 3. We keep allow people to add content to EPEL4 due to things like extended support 4. Some other option I haven't though about yet.
I like 1 the best, because it only helps enforce lifecycle planning. And when I worked in big enterprise, I needed all the help I could get to be able to move systems. :) Plus it allows our maintainers to focus effort on 5/6 enhancements and fixes.
Any discussion or suggestions welcome.
[1] https://access.redhat.com/support/policy/updates/errata/
stahnma
On Tue, Jan 03, 2012 at 09:21:31PM -0800, Michael Stahnke wrote:
So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and thus triggering CentOS, and I imagine Oracle, Scientific et al).
What are the plans for EPEL 4?
The way I see we have a few options:
- We stop putting new content in EPEL4 and take down the EPEL mirror (thus
really end-of-lifeing EPEL 4) 2. We stop putting in new content, and leave the mirrors, thus allowing those who haven't migrated to ahve some sort of package options, with no option for updates 3. We keep allow people to add content to EPEL4 due to things like extended support 4. Some other option I haven't though about yet.
Kind of a hybrid between 1) and 2) => Stop putting new content into EPEL4. Move current EPEL4 repositories to archives.fedoraproject.org. This shows that we're EOLing support for EPEL4 and also allows mirrors to opt out of carrying it but still lets people who are desperate to keep their RHEL/Centos4 boxes running a chance to benefit from the software that we built.
OTOH, I may be being selfish -- in Fedora Infrastructure we've long since moved away from RHEL4 (we're 3/4 of the way through migratin from RHEL5 to RHEL6 as well). I have a python module that's needed for running fedpkg on top of RHEL4 and if we drop EPEL4, I don't have to support that (and the python-2.3 compatibility that it entails) anymore.
-Toshio
Dne Út 3. ledna 2012 22:46:41, Toshio Kuratomi napsal(a):
On Tue, Jan 03, 2012 at 09:21:31PM -0800, Michael Stahnke
wrote:
So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and thus triggering CentOS, and I imagine Oracle, Scientific et al).
What are the plans for EPEL 4?
The way I see we have a few options:
- We stop putting new content in EPEL4 and take down the
EPEL mirror (thus really end-of-lifeing EPEL 4) 2. We stop putting in new content, and leave the mirrors, thus allowing those who haven't migrated to ahve some sort of package options, with no option for updates 3. We keep allow people to add content to EPEL4 due to things like extended support 4. Some other option I haven't though about yet.
I like 1 the best, because it only helps enforce lifecycle planning.
planning is a nice thing, but ... what if you are stuck with some hardware that works with the old software only, for example?
And when I worked in big enterprise, I needed all the help I could get to be able to move systems. :)
was it big enough to create its own software support team (I do not mean helpdesk but real developers) because it was way cheaper than to adapt to vendor's lifecycles? - why do you think that Red Hat created the EUS option?
Plus it allows our maintainers to focus effort on 5/6 enhancements and fixes.
see below
Kind of a hybrid between 1) and 2) => Stop putting new content into EPEL4. Move current EPEL4 repositories to archives.fedoraproject.org. This shows that we're EOLing support for EPEL4 and also allows mirrors to opt out of carrying it but still lets people who are desperate to keep their RHEL/Centos4 boxes running a chance to benefit from the software that we built.
OTOH, I may be being selfish -- in Fedora Infrastructure we've long since moved away from RHEL4 (we're 3/4 of the way through migratin from RHEL5 to RHEL6 as well). I have a python module that's needed for running fedpkg on top of RHEL4 and if we drop EPEL4, I don't have to support that (and the python-2.3 compatibility that it entails) anymore.
and if we do not drop EPEL4, what forces you to support the module?
- I thought we are talking about volunteer project ...
I'd prefer 3 - depending on what is meant by "adding content": bugfixes? - yes, if there's someone willing to take care new packages? - no, unless someone is really desperate (then he can create his own repo, for sure, but why not to allow him to use the existing EPEL infrastructure, are we short on hardware resources?)
K.
On 01/04/2012 07:21 AM, Michael Stahnke wrote:
So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and thus triggering CentOS, and I imagine Oracle, Scientific et al).
What are the plans for EPEL 4?
The way I see we have a few options:
- We stop putting new content in EPEL4 and take down the EPEL mirror
(thus really end-of-lifeing EPEL 4) 2. We stop putting in new content, and leave the mirrors, thus allowing those who haven't migrated to ahve some sort of package options, with no option for updates 3. We keep allow people to add content to EPEL4 due to things like extended support 4. Some other option I haven't though about yet.
I am for a combination of 2 and 3. I am 100% sure that even after RHEL4 goes end of life, many functional systems that are now running on RHEL4 will be preserved, even if there would be no new deployments. I see no reason to force them to stop using EPEL [*]. OTOH I do agree with Toshi's idea to migrate the repository to archives.f.o and allowing the public mirrors to opt-out.
I like 1 the best, because it only helps enforce lifecycle planning. And when I worked in big enterprise, I needed all the help I could get to be able to move systems. :)
Help as in "look, I want you to migrate, here is an argument you can use to convince your management and all the people who provide software for you: I'll cut access to the optional packages that you might wish to use" ??
Plus it allows our maintainers to focus effort on 5/6 enhancements and fixes.
I'd say it is up to maintainers to decide. FWIW, I know of an idiotic ( and niche ) medical application which still relies on Sybase 7 and the developers blindly refuse to support it on anything but RHEL 4. Or Windows (where they do use Sybase 9...). And no, I could not persuade the users of that application to ditch the application and use something decent and written in this century.
[*] assuming they do use it, of course
2012/1/4 Karel Volný kvolny@redhat.com
Dne Út 3. ledna 2012 22:46:41, Toshio Kuratomi napsal(a):
On Tue, Jan 03, 2012 at 09:21:31PM -0800, Michael Stahnke
wrote:
So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and thus triggering CentOS, and I imagine Oracle, Scientific et al).
What are the plans for EPEL 4?
The way I see we have a few options:
- We stop putting new content in EPEL4 and take down the
EPEL mirror (thus really end-of-lifeing EPEL 4) 2. We stop putting in new content, and leave the mirrors, thus allowing those who haven't migrated to ahve some sort of package options, with no option for updates 3. We keep allow people to add content to EPEL4 due to things like extended support 4. Some other option I haven't though about yet.
I like 1 the best, because it only helps enforce lifecycle planning.
planning is a nice thing, but ... what if you are stuck with some hardware that works with the old software only, for example?
Well the hardware that won't run something newer is probably approaching 10 years old at this point. It's probably time for an upgrade, or virtualization.
And when I worked in big enterprise, I needed all the help I could get to be able to move systems. :)
was it big enough to create its own software support team (I do not mean helpdesk but real developers) because it was way cheaper than to adapt to vendor's lifecycles?
Yes it was large enough, but that wasn't a good option. Moving on a planned schedule, though difficult is often the cheapest and best solution.
- why do you think that Red Hat created the EUS option?
Because people can't write software that doesn't break API/ABI, and to penalize them for that, Red Hat can charge more? :) We had 4,000 RHEL systems and never bought that once.
Plus it allows our maintainers to focus effort on 5/6 enhancements and fixes.
see below
Kind of a hybrid between 1) and 2) => Stop putting new content into EPEL4. Move current EPEL4 repositories to archives.fedoraproject.org. This shows that we're EOLing support for EPEL4 and also allows mirrors to opt out of carrying it but still lets people who are desperate to keep their RHEL/Centos4 boxes running a chance to benefit from the software that we built.
OTOH, I may be being selfish -- in Fedora Infrastructure we've long since moved away from RHEL4 (we're 3/4 of the way through migratin from RHEL5 to RHEL6 as well). I have a python module that's needed for running fedpkg on top of RHEL4 and if we drop EPEL4, I don't have to support that (and the python-2.3 compatibility that it entails) anymore.
and if we do not drop EPEL4, what forces you to support the module?
When you put something into EPEL, you are more-or-less agreeing to attempt to support it throughout the life of the operating systems EPEL is tracking. If we stop tracking EPEL4, people who have been trying to keep compatibility with E4, and back port fixes, etc will get a significant amount of time (in some cases) back.
- I thought we are talking about volunteer project ...
It is. It's also primarily in use by business customers this is why
planning and communication is key.
I'd prefer 3 - depending on what is meant by "adding content": bugfixes? - yes, if there's someone willing to take care new packages? - no, unless someone is really desperate (then he can create his own repo, for sure, but why not to allow him to use the existing EPEL infrastructure, are we short on hardware resources?)
K.
-- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp kavol@jabber.cz :: "Never attribute to malice what can :: easily be explained by stupidity." _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Wed, Jan 4, 2012 at 1:55 AM, Manuel Wolfshant wolfy@nobugconsulting.rowrote:
On 01/04/2012 07:21 AM, Michael Stahnke wrote:
So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and thus triggering CentOS, and I imagine Oracle, Scientific et al).
What are the plans for EPEL 4?
The way I see we have a few options:
- We stop putting new content in EPEL4 and take down the EPEL mirror
(thus really end-of-lifeing EPEL 4) 2. We stop putting in new content, and leave the mirrors, thus allowing those who haven't migrated to ahve some sort of package options, with no option for updates 3. We keep allow people to add content to EPEL4 due to things like extended support 4. Some other option I haven't though about yet.
I am for a combination of 2 and 3. I am 100% sure that even after RHEL4
goes end of life, many functional systems that are now running on RHEL4 will be preserved, even if there would be no new deployments. I see no reason to force them to stop using EPEL [*]. OTOH I do agree with Toshi's idea to migrate the repository to archives.f.o and allowing the public mirrors to opt-out.
I like the archives proposal as well.
I like 1 the best, because it only helps enforce lifecycle planning. And when I worked in big enterprise, I needed all the help I could get to be able to move systems. :)
Help as in "look, I want you to migrate, here is an argument you can use to convince your management and all the people who provide software for you: I'll cut access to the optional packages that you might wish to use" ??
It would just be another data point. We tried to plan our life cycles of technologies as the OS went into the data center.
Plus it allows our maintainers to focus effort on 5/6 enhancements and
fixes.
I'd say it is up to maintainers to decide. FWIW, I know of an idiotic ( and niche ) medical application which still relies on Sybase 7 and the developers blindly refuse to support it on anything but RHEL 4. Or Windows (where they do use Sybase 9...). And no, I could not persuade the users of that application to ditch the application and use something decent and written in this century.
[*] assuming they do use it, of course
______________________________**_________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/**mailman/listinfo/epel-devel-**listhttps://www.redhat.com/mailman/listinfo/epel-devel-list
On 3 January 2012 22:21, Michael Stahnke mastahnke@gmail.com wrote:
So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and thus triggering CentOS, and I imagine Oracle, Scientific et al).
What are the plans for EPEL 4?
The way I see we have a few options:
1. We stop putting new content in EPEL4 and take down the EPEL mirror (thus really end-of-lifeing EPEL 4) 2. We stop putting in new content, and leave the mirrors, thus allowing those who haven't migrated to ahve some sort of package options, with no option for updates 3. We keep allow people to add content to EPEL4 due to things like extended support 4. Some other option I haven't though about yet.
I like 1 the best, because it only helps enforce lifecycle planning. And when I worked in big enterprise, I needed all the help I could get to be able to move systems. :) Plus it allows our maintainers to focus effort on 5/6 enhancements and fixes.
Any discussion or suggestions welcome.
I would like to "vote" for option 1 with an updated epel-4 release that points to archives location. The reason is the following:
1) The Builders will not have access to EUS and so will effectively be building at 4.9 forever. 2) Building stuff for EL-4 is becoming harder and harder and extending the lifetime that maintainers who signed up to EOL is now 4 years longer. That means either removing stuff from EPEL or finding another maintainer (effectively doing the same).
On Tue, 3 Jan 2012 22:46:41 -0800 Toshio Kuratomi a.badger@gmail.com wrote:
Kind of a hybrid between 1) and 2) => Stop putting new content into EPEL4. Move current EPEL4 repositories to archives.fedoraproject.org. This shows that we're EOLing support for EPEL4 and also allows mirrors to opt out of carrying it but still lets people who are desperate to keep their RHEL/Centos4 boxes running a chance to benefit from the software that we built.
I like this plan.
kevin
Dne St 4. ledna 2012 08:09:31, Michael Stahnke napsal(a):
planning is a nice thing, but ... what if you are stuck with some hardware that works with the old software only, for example?
Well the hardware that won't run something newer is probably approaching 10 years old at this point. It's probably time for an upgrade, or virtualization.
LOL, I got a bit amused trying to imagine how are you virtualizing a large scale CNC machine ... :-)
well, I have no clue what are the real usages of RHEL4+EPEL
but I just don't like the attitude
it has bitten me just a few weeks ago - why should I buy a new printer when the twelve years old one is in perfect shape, it provides a good quality, and the price per page ratio is the lowest in its class?
I'd rather pay the price of the new printer to someone to fix the driver to work with new kernel than to throw away the old one, trashing the Earth with another piece of waste
And when I worked in big enterprise, I needed all the help I could get to be able to move systems. :)
was it big enough to create its own software support team (I do not mean helpdesk but real developers) because it was way cheaper than to adapt to vendor's lifecycles?
Yes it was large enough, but that wasn't a good option. Moving on a planned schedule, though difficult is often the cheapest and best solution.
now you say "is often" - and what about the rest of cases (e.g. my experience is different, or the managers in my previous company just couldn't do the math ...)?
will supporting them negatively affect the majority? - I don't think so
will supporting them cost us more than it would cost them if we dropped the support? - don't know ... but as we are talking about moving things to archive, i.e. eating the same disk space, just under another directory, I doubt our costs would be significant in comparison
...
and if we do not drop EPEL4, what forces you to support the module?
When you put something into EPEL, you are more-or-less agreeing to attempt to support it throughout the life of the operating systems EPEL is tracking. If we stop tracking EPEL4, people who have been trying to keep compatibility with E4, and back port fixes, etc will get a significant amount of time (in some cases) back.
this does not answer my question
okay, you "agreed to attempt" - now what?
- I thought we are talking about volunteer project ...
It is. It's also primarily in use by business customers this is why planning and communication is key.
so, wouldn't it be better to communicate with these customers and present some resume rather then push everyone's selfish agenda on this list?
K.
On Thu, Jan 05, 2012 at 01:33:31PM +0100, Karel Volný wrote:
but I just don't like the attitude
it has bitten me just a few weeks ago - why should I buy a new printer when the twelve years old one is in perfect shape, it provides a good quality, and the price per page ratio is the lowest in its class?
I'd rather pay the price of the new printer to someone to fix the driver to work with new kernel than to throw away the old one, trashing the Earth with another piece of waste
There's two differences that I can see:
* We're only talking about throwing away support here. If people can still get the old packages on archives.fp.o, we're really just saying that we don't support the software anymore (with updates, handling of bug reports, etc). The product is still available for those who want it. * The product we're throwing out is software, not hardware. So there's no physical waste when abandoning it.
And when I worked in big enterprise, I needed all the help I could get to be able to move systems. :)
was it big enough to create its own software support team (I do not mean helpdesk but real developers) because it was way cheaper than to adapt to vendor's lifecycles?
Yes it was large enough, but that wasn't a good option. Moving on a planned schedule, though difficult is often the cheapest and best solution.
now you say "is often" - and what about the rest of cases (e.g. my experience is different, or the managers in my previous company just couldn't do the math ...)?
will supporting them negatively affect the majority? - I don't think so
will supporting them cost us more than it would cost them if we dropped the support? - don't know ... but as we are talking about moving things to archive, i.e. eating the same disk space, just under another directory, I doubt our costs would be significant in comparison
The true cost is in manpower for whoever has to maintain the packages, fix bugs, update software, etc. EPEL is based on the idea that it costs us less to collectively package software than it does for individuals to package the same software separately so in absolute numbers, you're probably right that our costs are lower than theirs.
However, our manpower comes from volunteers who need to consider what they're doing as fun whereas their manpower comes from paid employees who need to be convinced that their employers are doing what's most beneficial for the company. Maintaining software that doesn't run on any machines that I have deployed and whose core software is so old is much less fun than maintaining software for the latest releases. When you contrast this with someone who is being paid to maintain a RHEL4 machine and needs the software being packaged to run on that machine. I think the relative cost for us becomes much higher.
Note that there are other options here. In Fedora, the decision was an "all packages or no packages" approach. A group could work on a Fedora Legacy to extend the EOL date only if they maintained all packages for a longer period. In RHEL4 itself, it appears that Red Hat is going to select a subset of packages that may receive updates. Other packages will not (even if the package has a security flaw). I suppose that we could follow that model if less than the whole set of EPEL contributors wanted to continue on with EPEL4. However, doing this might mean that you also had to allocate manpower to do rel-eng tasks related to building, signing, and pushing updates; document which packages the EPEL4 group was willing to continue maintainance on; pick up the slack on each others packages if someone stops contributing to EPEL4; etc.
...
and if we do not drop EPEL4, what forces you to support the module?
When you put something into EPEL, you are more-or-less agreeing to attempt to support it throughout the life of the operating systems EPEL is tracking. If we stop tracking EPEL4, people who have been trying to keep compatibility with E4, and back port fixes, etc will get a significant amount of time (in some cases) back.
this does not answer my question
okay, you "agreed to attempt" - now what?
I suppose the next question is how long did you/I/we "agree to attempt"?
I agreed to go until EOL; not to the end of extended life. But I don't see that canonified on the EPEL wiki and policy pages... so it must have just been what we talked about on the mailing lists back in 2006 and 2007.
- I thought we are talking about volunteer project ...
It is. It's also primarily in use by business customers this is why planning and communication is key.
so, wouldn't it be better to communicate with these customers and present some resume rather then push everyone's selfish agenda on this list?
Well... what I see is that we're determining if there's manpower here to support EPEL4 past EOL. If there isn't manpower, our message is "EPEL will not be supporting RHEL4 after RHEL4's End of Production date, Feb 29, 2012."
If there is manpower, I suppose the message changes.
Since our users aren't paying us, figuring out what our non-contributing user's needs are, while nice to know, is not very rewarding. The "selfish agenda" that you speak of is much more important to this equation -- it's the expression of whether we feel we're being paid enough to continue to do the work that we do in EPEL4.
-Toshio
On 5 January 2012 10:32, Toshio Kuratomi a.badger@gmail.com wrote:
On Thu, Jan 05, 2012 at 01:33:31PM +0100, Karel Volný wrote:
I suppose the next question is how long did you/I/we "agree to attempt"?
I agreed to go until EOL; not to the end of extended life. But I don't see that canonified on the EPEL wiki and policy pages... so it must have just been what we talked about on the mailing lists back in 2006 and 2007.
Originally it was only until EOL and was very clear about that. It was one of the reasons why we didn't support EL-3 as it was coming up to EOL and while it would have EUS, it was not something we had support for. I am not much interested in supporting EL-4 as I have had to pull all my packages from it already. They either don't build or require fixes which are beyond my skill to accomplish. I also have no EL-4 systems that I run anymore so it isn't 'fun'.
Hello...
On Tue, 2012-01-03 at 21:21 -0800, Michael Stahnke wrote:
So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and thus triggering CentOS, and I imagine Oracle, Scientific et al).
What are the plans for EPEL 4?
The way I see we have a few options:
- We stop putting new content in EPEL4 and take down the EPEL mirror
(thus really end-of-lifeing EPEL 4) 2. We stop putting in new content, and leave the mirrors, thus allowing those who haven't migrated to ahve some sort of package options, with no option for updates 3. We keep allow people to add content to EPEL4 due to things like extended support 4. Some other option I haven't though about yet.
What happens to the git repo branches? If the branches stay then anyone still using RHEL4 could use git checkout, fedpkg, and mock to build their own packages with any security patches they need.
I like 1 the best, because it only helps enforce lifecycle planning. And when I worked in big enterprise, I needed all the help I could get to be able to move systems. :) Plus it allows our maintainers to focus effort on 5/6 enhancements and fixes.
Any discussion or suggestions welcome.
[1] https://access.redhat.com/support/policy/updates/errata/
stahnma
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Thu, Jan 05, 2012 at 11:40:36AM -0800, Christopher McCrory wrote:
Hello...
On Tue, 2012-01-03 at 21:21 -0800, Michael Stahnke wrote:
So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and thus triggering CentOS, and I imagine Oracle, Scientific et al).
What are the plans for EPEL 4?
The way I see we have a few options:
- We stop putting new content in EPEL4 and take down the EPEL mirror
(thus really end-of-lifeing EPEL 4) 2. We stop putting in new content, and leave the mirrors, thus allowing those who haven't migrated to ahve some sort of package options, with no option for updates 3. We keep allow people to add content to EPEL4 due to things like extended support 4. Some other option I haven't though about yet.
What happens to the git repo branches? If the branches stay then anyone still using RHEL4 could use git checkout, fedpkg, and mock to build their own packages with any security patches they need.
The git branches will remain. I don't believe we'd even close them out for commits (Extra work to script that ;-). koji would probably be closed to new builds (even scratch), though.
-Toshio
On Thu, 5 Jan 2012 11:53:40 -0800 Toshio Kuratomi a.badger@gmail.com wrote:
On Thu, Jan 05, 2012 at 11:40:36AM -0800, Christopher McCrory wrote:
Hello...
...snip...
What happens to the git repo branches? If the branches stay then anyone still using RHEL4 could use git checkout, fedpkg, and mock to build their own packages with any security patches they need.
The git branches will remain. I don't believe we'd even close them out for commits (Extra work to script that ;-). koji would probably be closed to new builds (even scratch), though.
Yeah, another saving of resources here would be that infrastructure would no longer need to sync rhel4 repos, koji wouldn't need a tag to run newrepo tasks on for epel4, and we would not need to mash and push epel4 updates.
I really think the best action here is to do what Fedora does... move rpms to archive, git branches stay, but koji drops support as does infrastructure.
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Wed, 4 Jan 2012 11:39:26 -0700 Kevin Fenzi kevin@scrye.com escribió:
On Tue, 3 Jan 2012 22:46:41 -0800 Toshio Kuratomi a.badger@gmail.com wrote:
Kind of a hybrid between 1) and 2) => Stop putting new content into EPEL4. Move current EPEL4 repositories to archives.fedoraproject.org. This shows that we're EOLing support for EPEL4 and also allows mirrors to opt out of carrying it but still lets people who are desperate to keep their RHEL/Centos4 boxes running a chance to benefit from the software that we built.
I like this plan.
kevin
+1 from me also.
and Kevin and I are the guys that make the bits available to the world
Dennis
epel-devel@lists.fedoraproject.org
-
Christopher McCrory -
Dennis Gilmore -
Karel Volný -
Kevin Fenzi -
Manuel Wolfshant -
Michael Stahnke -
Stephen John Smoogen -
Toshio Kuratomi