FP! :-)
Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL.
- Do we want a moving (and potentially breaking) set of packages which is constantly being updated? - De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
Or maybe something in between, or even both at the same time in separate repositories... all is possible, as long as we have enough man power to make it happen.
Matthias
Matthias Saou wrote:
FP! :-)
Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL.
- Do we want a moving (and potentially breaking) set of packages which is constantly being updated?
- Do we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
While some folks certainly have an interest in the latter, I think it wiser to simply focus on the former, at least until we reach a critical mass of packages/maintainers. At that point, reconsideration would be reasonable.
-- Rex
On Tuesday 27 February 2007 01:30:50 pm Matthias Saou wrote:
FP! :-)
Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL.
- Do we want a moving (and potentially breaking) set of packages which is constantly being updated?
- De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
Or maybe something in between, or even both at the same time in separate repositories... all is possible, as long as we have enough man power to make it happen.
Matthias
I think somewhere in between. with the maintainer being responsible for making the decision. basically we want it to be as stable and consistent as possible but some times it just makes sense to update to a newer version.
Matthias Saou (thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said:
- Do we want a moving (and potentially breaking) set of packages which is constantly being updated?
- De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
Or maybe something in between, or even both at the same time in separate repositories... all is possible, as long as we have enough man power to make it happen.
I'd lean somewhat towards the latter. If we actually intend to maintain stuff for 7 years, we're not going to be wanting to do that many upgrades.
Are packagers really signing up for backporting?
Bill
On Tue, Feb 27, 2007 at 02:46:04PM -0500, Bill Nottingham wrote:
Matthias Saou (thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said:
- Do we want a moving (and potentially breaking) set of packages which is constantly being updated?
- De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
Or maybe something in between, or even both at the same time in separate repositories... all is possible, as long as we have enough man power to make it happen.
I'd lean somewhat towards the latter. If we actually intend to maintain stuff for 7 years, we're not going to be wanting to do that many upgrades.
Are packagers really signing up for backporting?
A good question, backporting is the name of evil in software engineering and packaging. FL died on the amount of efforts this requires. Simply upgrading is the fast way out, but maybe not the RHEL API/ABI stable way.
Backporting would be really great, but we need tons of slaves or masochists to commit to this. Maybe it depends on how many paid jobs from RH and external will be involved, since volunteers are less likely to do backporting.
I would say, if we think that manpower will be low, we need to follow a rolling release model w/o backporting. If we know that there is enough momentum and interest (in the sense of doing it, not just wanting it) then we should consider backporting, it would raise quality/stability standards to two of the "E"s in RHEL/EPEL ;)
On 27.02.2007 20:30, Matthias Saou wrote:
Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL.
Do we want a moving (and potentially breaking) set of packages which is constantly being updated?
De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
A mix afaics. Not that rolling like Extras was, but a bit rolling.
In other words: We IMHO should have a two repos per release:
- a testing repo, where new package and bigger updates enter and get tested for a while. They get moved to the proper repo with each RHEL update (say 4.4 -> 4.5)
- a proper repo, that only gets updates for security reasons or to fix major bugs
We should also make sure that we have a mostly constant look and feel to the outside. That's why I wrote this for the wiki:
--- Is these packages a rolling release with "latest and greatest software" or a more "stable base and updates only when really needed"?
That needs to be discussed. But it will probably be a mix -- for example, a kind of rolling release, but with a careful and strict update policy where parts are only updated for a good reason, or not at all. Updating to the latest and greatest version is not possible in most cases, as a lot of newer packages depend on new versions of certain core-libs (for example, gtk, qt, and many others), which are often not available once the supported distribution is 12 months or older.
It also does not make sense to have a repo where some packages are always latest while most others and the distribution are on older versions.
The nature of the distributions in question show the user choice. These users prefer a stable base -- that's why they are using an Enterprise-class distribution that only gets updates every ~18 months. So why should an add-on repository for an Enterprise-class distribution be different? ---
CU thl
On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote:
FP! :-)
Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL.
- Do we want a moving (and potentially breaking) set of packages which is constantly being updated?
The CentOS way
- De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
More RHEL like
You'll find that people in favour of one will come from the respective camp. *RHEL* customers are usually really fixated in using RHEL 5.3 and not something between 5.3 and 5.4. Same for Scientific Linux. CentOS OTOH more on running the latests.
So, it's up to the target audience you want to please. I think RHEL's fastrack may be a good model. You prepare packages for RHEL 5.(N+1) and make it already available there. Users can then decide to stick with minor release + security updates or slide on a rolling like release from RHEL 5.N to RHEL 5.(N+1).
Maybe we even have to do that that way, if we want to claim full RHEL support. Otherwise we may be enforcing different update models to RHEL users than they have with RHEL pure.
On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote:
On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote:
FP! :-)
Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL.
- Do we want a moving (and potentially breaking) set of packages which is constantly being updated?
The CentOS way
- De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
More RHEL like
FWIW, the CentOS people I spoke to at FOSDEM were very much interested in the "fixed set, with bugfixes and security updates only" model.
~spot
Tom 'spot' Callaway wrote :
On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote:
On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote:
FP! :-)
Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL.
- Do we want a moving (and potentially breaking) set of packages which is constantly being updated?
The CentOS way
- De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
More RHEL like
FWIW, the CentOS people I spoke to at FOSDEM were very much interested in the "fixed set, with bugfixes and security updates only" model.
...but also in providing a lot of recent stuff. They already have php 5 and mysql 5 in a separate location for people to use on CentOS 4.
Matthias
Matthias Saou schrieb:
Tom 'spot' Callaway wrote :
On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote:
On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote:
FP! :-) Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL.
- Do we want a moving (and potentially breaking) set of packages which is constantly being updated?
The CentOS way
- De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
More RHEL like
FWIW, the CentOS people I spoke to at FOSDEM were very much interested in the "fixed set, with bugfixes and security updates only" model.
I agree with the "fixed set, with bugfixes and security updates only", too.
But also with this:
...but also in providing a lot of recent stuff. They already have php 5 and mysql 5 in a separate location for people to use on CentOS 4.
But I'd say we should leave this out for now until EPEL lift of, and find a a solution for this later.
CU thl
Wasn't Red Hat introducing something along the lines of a LAMP stack that rolls on top of RHEL? LIke it would actually have PHP5/MySQL 5(or maybe 4.1) on top of RHEL 4. It was a separate subscription I thought, but a valid idea. The latest software for what is needed, and stable known-good software for the rest.
I thought something like that was talked about at the RH summit last year.
I do think that a rolling release on top of a no API/ABI breakage release would be very difficult to do, and tend to agree that targetting minor releases for updates probably makes the most sense for users and developers.
On 3/1/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Matthias Saou schrieb:
Tom 'spot' Callaway wrote :
On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote:
On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote:
FP! :-) Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL.
- Do we want a moving (and potentially breaking) set of packages which is constantly being updated?
The CentOS way
- De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
More RHEL like
FWIW, the CentOS people I spoke to at FOSDEM were very much interested in the "fixed set, with bugfixes and security updates only" model.
I agree with the "fixed set, with bugfixes and security updates only", too.
But also with this:
...but also in providing a lot of recent stuff. They already have php 5 and mysql 5 in a separate location for people to use on CentOS 4.
But I'd say we should leave this out for now until EPEL lift of, and find a a solution for this later.
CU thl
Epel-devel-list mailing list Epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Thu, 2007-03-01 at 11:31 -0600, Michael Stahnke wrote:
Wasn't Red Hat introducing something along the lines of a LAMP stack that rolls on top of RHEL? LIke it would actually have PHP5/MySQL 5(or maybe 4.1) on top of RHEL 4. It was a separate subscription I thought, but a valid idea. The latest software for what is needed, and stable known-good software for the rest.
Yep, launched last September. From the right-side column here:
https://rhstack.108.redhat.com
... is this list of apps and versions:
HTTPD Apache 2.0.59 JBoss AS 4.0.5 MySQL 5.0.30 PHP 5.1.6 Perl 5.8.8 PostgreSQL 8.1.8 Red Hat Enterprise Linux 4 Update 4
I suppose that makes those applications and versions not eligible to be packages in EPEL? Is eligibility decided by applications or specific versions or both? Or some other combination?
- Karsten
Once upon a time Thursday 01 March 2007, Karsten Wade wrote:
On Thu, 2007-03-01 at 11:31 -0600, Michael Stahnke wrote:
Wasn't Red Hat introducing something along the lines of a LAMP stack that rolls on top of RHEL? LIke it would actually have PHP5/MySQL 5(or maybe 4.1) on top of RHEL 4. It was a separate subscription I thought, but a valid idea. The latest software for what is needed, and stable known-good software for the rest.
Yep, launched last September. From the right-side column here:
https://rhstack.108.redhat.com
... is this list of apps and versions:
HTTPD Apache 2.0.59 JBoss AS 4.0.5 MySQL 5.0.30 PHP 5.1.6 Perl 5.8.8 PostgreSQL 8.1.8 Red Hat Enterprise Linux 4 Update 4
I suppose that makes those applications and versions not eligible to be packages in EPEL? Is eligibility decided by applications or specific versions or both? Or some other combination?
EPEL packages are not to replace packages in RHEL so of those we could maybe include JBoss. though things get murky when it comes to Red Hat add on's
Dennis
On 02.03.2007 13:36, Dennis Gilmore wrote:
Once upon a time Thursday 01 March 2007, Karsten Wade wrote:
On Thu, 2007-03-01 at 11:31 -0600, Michael Stahnke wrote:
Wasn't Red Hat introducing something along the lines of a LAMP stack that rolls on top of RHEL? LIke it would actually have PHP5/MySQL 5(or maybe 4.1) on top of RHEL 4. It was a separate subscription I thought, but a valid idea. The latest software for what is needed, and stable known-good software for the rest.
Yep, launched last September. From the right-side column here: https://rhstack.108.redhat.com ... is this list of apps and versions: HTTPD Apache 2.0.59 JBoss AS 4.0.5 MySQL 5.0.30 PHP 5.1.6 Perl 5.8.8 PostgreSQL 8.1.8 Red Hat Enterprise Linux 4 Update 4 I suppose that makes those applications and versions not eligible to be packages in EPEL? Is eligibility decided by applications or specific versions or both? Or some other combination?
EPEL packages are not to replace packages in RHEL so of those we could maybe include JBoss.
+1 (including the maybe)
though things get murky when it comes to Red Hat add on's
Exactly...
Not sure, maybe the compromise needs to be something like this: --- EPEL Packages must not replace or conflict(¹) with Packages from it's base (e.g. RHEL) or directly related Add-On-Packages for it, that got released in the same timeframe as the RHEL-Release. ---
CU thl
(¹) -- conflict in the real life meaning of conflict, not the "Conflict:" usage in RPM (that's another discussion for later)
On 3/2/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 02.03.2007 13:36, Dennis Gilmore wrote:
Once upon a time Thursday 01 March 2007, Karsten Wade wrote:
On Thu, 2007-03-01 at 11:31 -0600, Michael Stahnke wrote:
Wasn't Red Hat introducing something along the lines of a LAMP stack that rolls on top of RHEL? LIke it would actually have PHP5/MySQL 5(or maybe 4.1) on top of RHEL 4. It was a separate subscription I thought, but a valid idea. The latest software for what is needed, and stable known-good software for the rest.
Yep, launched last September. From the right-side column here: https://rhstack.108.redhat.com ... is this list of apps and versions: HTTPD Apache 2.0.59 JBoss AS 4.0.5 MySQL 5.0.30 PHP 5.1.6 Perl 5.8.8 PostgreSQL 8.1.8 Red Hat Enterprise Linux 4 Update 4 I suppose that makes those applications and versions not eligible to be packages in EPEL? Is eligibility decided by applications or specific versions or both? Or some other combination?
EPEL packages are not to replace packages in RHEL so of those we could maybe include JBoss.
+1 (including the maybe)
though things get murky when it comes to Red Hat add on's
I guess I assumed we were not aiming to replace RHEL base packages. As for the other channels of software, we probably need to visit each one. Does CentOS or Scientific currently repackage the other channels that RH normally charges subscription for? Excuse my ignorance, we are strictly a RHEL shop.
For example, Directory Server, Application Server, Developer Suite Channel, etc are all add-on channels that have a lot of great packages but are not part of the core RHEL base. Maybe it's a good topic for this weekend's meeting?
Exactly...
Not sure, maybe the compromise needs to be something like this:
EPEL Packages must not replace or conflict(¹) with Packages from it's base (e.g. RHEL) or directly related Add-On-Packages for it, that got released in the same timeframe as the RHEL-Release.
CU thl
(¹) -- conflict in the real life meaning of conflict, not the "Conflict:" usage in RPM (that's another discussion for later)
Epel-devel-list mailing list Epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Friday 02 March 2007 08:33:19 am Michael Stahnke wrote:
I guess I assumed we were not aiming to replace RHEL base packages. As for the other channels of software, we probably need to visit each one. Does CentOS or Scientific currently repackage the other channels that RH normally charges subscription for? Excuse my ignorance, we are strictly a RHEL shop.
For example, Directory Server, Application Server, Developer Suite Channel, etc are all add-on channels that have a lot of great packages but are not part of the core RHEL base. Maybe it's a good topic for this weekend's meeting?
AFAIK they don't. but i have never really looked.
Directory server is a special case. There is Red Hat Directory Server which is paid for and comes with support etc. Then there is Fedora Directory Server which is Free and comes with community support. I already have buy in from the Directory Server guys to get Fedora Directory Server into EPEL.
Both use the same code base.
Bill Nottingham schrieb:
Michael Stahnke (mastahnke@gmail.com) said:
I guess I assumed we were not aiming to replace RHEL base packages.
What happens when a package targeted for EPEL requires a bug fix in a RHEL package? (This is not theoretical, I have one of these.)
AFIACS the same as in Extras in the past: File a bug, poke Red Hat maintainers (¹) and pray that it gets fixed.
Especially the last part is important.
Sorry, sound like a joke, and in parts is one, but well, on the other hands that's how it roughly worked for community contributors in Extras(²).
CU thl
(¹) maybe with the help of a friendly red hat employee like notting or jeremy that can poke in real life, too
(²) praying is optional and you can use the god of your choice
Thorsten Leemhuis (fedora@leemhuis.info) said:
AFIACS the same as in Extras in the past: File a bug, poke Red Hat maintainers (¹) and pray that it gets fixed.
Especially the last part is important.
Sorry, sound like a joke, and in parts is one, but well, on the other hands that's how it roughly worked for community contributors in Extras(²).
Sure, but it's actually a lot easier to get things fixed in Fedora, especially if it's just 'grab a newer version'. I'm not sure I can convincingly come up with a business case for rebasing guile for RHEL 4. :)
Bill
Bill Nottingham schrieb:
Thorsten Leemhuis (fedora@leemhuis.info) said:
AFIACS the same as in Extras in the past: File a bug, poke Red Hat maintainers (¹) and pray that it gets fixed. Especially the last part is important. Sorry, sound like a joke, and in parts is one, but well, on the other hands that's how it roughly worked for community contributors in Extras(²).
Sure, but it's actually a lot easier to get things fixed in Fedora,
From my point of view it seems quite hard sometimes... But that's a
different story...
especially if it's just 'grab a newer version'. I'm not sure I can convincingly come up with a business case for rebasing guile for RHEL 4. :)
:-)
Anyway, do you have any proposed solution for the problem at hand that not involves replacing or disturbing pacakges from RHEL? Then I'm all ears...
CU thl
On 3/2/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Bill Nottingham schrieb:
Thorsten Leemhuis (fedora@leemhuis.info) said:
AFIACS the same as in Extras in the past: File a bug, poke Red Hat maintainers (¹) and pray that it gets fixed. Especially the last part is important. Sorry, sound like a joke, and in parts is one, but well, on the other hands that's how it roughly worked for community contributors in Extras(²).
Sure, but it's actually a lot easier to get things fixed in Fedora,
From my point of view it seems quite hard sometimes... But that's a
different story...
especially if it's just 'grab a newer version'. I'm not sure I can convincingly come up with a business case for rebasing guile for RHEL 4. :)
:-)
Anyway, do you have any proposed solution for the problem at hand that not involves replacing or disturbing pacakges from RHEL? Then I'm all ears...
That would be the APEL list... with a nice APEL with a worm in it.
On Fri, Mar 02, 2007 at 06:44:50PM +0100, Thorsten Leemhuis wrote:
Bill Nottingham schrieb:
Thorsten Leemhuis (fedora@leemhuis.info) said:
AFIACS the same as in Extras in the past: File a bug, poke Red Hat maintainers (¹) and pray that it gets fixed. Especially the last part is important. Sorry, sound like a joke, and in parts is one, but well, on the other hands that's how it roughly worked for community contributors in Extras(²).
Sure, but it's actually a lot easier to get things fixed in Fedora,
From my point of view it seems quite hard sometimes... But that's a
different story...
especially if it's just 'grab a newer version'. I'm not sure I can convincingly come up with a business case for rebasing guile for RHEL 4. :)
:-)
Anyway, do you have any proposed solution for the problem at hand that not involves replacing or disturbing pacakges from RHEL? Then I'm all ears...
I don't know, maybe it shows that the all-frightened "don't replace" sign paved everywhere isn't the holy grail afterall. When even one section in Red Hat replaces packages from RHEL for LAMP ...
Axel Thimm schrieb:
On Fri, Mar 02, 2007 at 06:44:50PM +0100, Thorsten Leemhuis wrote:
Bill Nottingham schrieb:
Thorsten Leemhuis (fedora@leemhuis.info) said:
AFIACS the same as in Extras in the past: File a bug, poke Red Hat maintainers (¹) and pray that it gets fixed. Especially the last part is important. Sorry, sound like a joke, and in parts is one, but well, on the other hands that's how it roughly worked for community contributors in Extras(²).
Sure, but it's actually a lot easier to get things fixed in Fedora, From my point of view it seems quite hard sometimes... But that's a
different story...
especially if it's just 'grab a newer version'. I'm not sure I can convincingly come up with a business case for rebasing guile for RHEL 4. :)
:-) Anyway, do you have any proposed solution for the problem at hand that not involves replacing or disturbing pacakges from RHEL? Then I'm all ears...
I don't know, maybe it shows that the all-frightened "don't replace" sign paved everywhere isn't the holy grail afterall.
I think it is still important for us to not replace stuff in the main repo.
But we could have a (or even a lot more) repo that replaces stuff (or puts it in parallel into /opt or something) in parallel to the holy-grail-do-not-replace-EPEL-repo if we really want to. But I'd would like to get the do-not-replace-EPEL-repo started first before we start thinking about things like that.
When even one section in Red Hat replaces packages from RHEL for LAMP ...
Well, there is afaics a great difference in these two scenarios:
1: - customer buys RHEL - customer buys RHEL add-on foo - customer has a problem with RHEL package bar from RHEL due to one of the package from foo - calls RH support and problem get solved, as both products are from RH so there is no chance for them to ignore the problem
2: - customer buys RHEL - customer get package foo from EPEL that ships with a new bar which replaces bar shipped by RHEL - customer has a problem with bar or another package depending on bar - calls RH support and problem get ignored: "not our package, we can't help"
CU thl
On Sat, Mar 03, 2007 at 07:01:31AM +0100, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
On Fri, Mar 02, 2007 at 06:44:50PM +0100, Thorsten Leemhuis wrote:
Bill Nottingham schrieb:
especially if it's just 'grab a newer version'. I'm not sure I can convincingly come up with a business case for rebasing guile for RHEL 4. :)
:-) Anyway, do you have any proposed solution for the problem at hand that not involves replacing or disturbing pacakges from RHEL? Then I'm all ears...
I don't know, maybe it shows that the all-frightened "don't replace" sign paved everywhere isn't the holy grail afterall.
I think it is still important for us to not replace stuff in the main repo.
I'm not suggesting the main repo (well, I'm not suggesting anything at this point in time, I'll let Bill suggest "epelplus" and take the blame ;)
When even one section in Red Hat replaces packages from RHEL for LAMP ...
Well, there is afaics a great difference in these two scenarios:
1:
- customer buys RHEL
- customer buys RHEL add-on foo
- customer has a problem with RHEL package bar from RHEL due to one of
the package from foo
- calls RH support and problem get solved, as both products are from RH
so there is no chance for them to ignore the problem
2:
- customer buys RHEL
- customer get package foo from EPEL that ships with a new bar which
replaces bar shipped by RHEL
- customer has a problem with bar or another package depending on bar
- calls RH support and problem get ignored: "not our package, we can't
help"
Oh, we have much worse that that already in place:
3: - customer buys RHEL - customer get package foo from EPEL that ships with a bar which does not exist in RHEL, so everybody thinks it's fine - bar fubars customer's system (bar is a plugin, daemon, kernel module, or something similar) - customer report to RH that system does not work (doesn't boot, firefox crashes, kernel oops) - RH speds support time on customer only to find out that the bug is not directly in firefox/kernel/etc. but in a pure add-on package
In fact in all these years of "replacements" 3) has happened far more often than 2) - the metrics would be 3)/#add-ons compared to 2)/#replacment, but 2) is very close to zero.
So, if we are not in a worse position that we already are, why not benefit and have Bill update/fix guille in the "epelplus" repo?
On Wed, Mar 07, 2007 at 04:07:21PM -0500, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@ATrpms.net) said:
why not benefit and have Bill update/fix guille
Because I don't really care about guile, I just want my app to work. :)
But didn't you mention that you need to update/fix guille for your app's sake? That's all I wanted to say, I didn't suggest to place guille on your plate ;)
On 3/3/07, Axel Thimm Axel.Thimm@atrpms.net wrote:
Oh, we have much worse that that already in place:
3:
- customer buys RHEL
- customer get package foo from EPEL that ships with a bar which does not exist in RHEL, so everybody thinks it's fine
- bar fubars customer's system (bar is a plugin, daemon, kernel module, or something similar)
- customer report to RH that system does not work (doesn't boot, firefox crashes, kernel oops)
- RH speds support time on customer only to find out that the bug is not directly in firefox/kernel/etc. but in a pure add-on package
In fact in all these years of "replacements" 3) has happened far more often than 2) - the metrics would be 3)/#add-ons compared to 2)/#replacment, but 2) is very close to zero.
So, if we are not in a worse position that we already are, why not benefit and have Bill update/fix guille in the "epelplus" repo?
This problem already exist for RH with third party packages / kernel modules / script installs. Third party stuff must account for a good 90% of the kernel dump cases we open with Red Hat. Their answer is simple, remove the third party stuff and reproduce the problem. Of course we can't but we do know who needs to do the fixing at this point.
From a customer standpoint the only difference I see between this and a EPEL
package is that (if my experience with FE holds true) I might actually get a fix with out needing to arrange twelve conference calls, and eventually refusing to pay another cent to the ISV. Y'all do a much better job than any ISV I've ever dealt with. Keep up the good work!
Now the case where a package has upgraded some thing Red Hat provides is another ball of wax. Red Hat still has the right to refuse to support someone else's package, but now its not as easy to get rid of. Sure I can downgrade but I'm sure some developer of mine will have found the only feature not implemented in the version Red Hat ships with. I'm constantly finding boxes where they've upgraded python and have broken all of the system utils, and more importantly yum.
The part that really worries me is the case where say Red Hat does decide to upgrade a package to a similar or higher version than the one provided by EPEL. Now I'm in some odd situation where either package may upgrade the other depending on how close they are to each other.
At least if there is a plus, bleeding, danger, whatever repo, I can use either the protectbase, or priorities plugin to yum to provide some degree of security. The brave souls willing to negate their support (or those running CentOS, ect. where support isn't the issue) can test the watters and report back to the more timid. ;-)
Russell
On Wed, Mar 07, 2007 at 07:59:27PM -0500, Russell Harrison wrote:
At least if there is a plus, bleeding, danger, whatever repo, I can use either the protectbase, or priorities plugin to yum to provide some degree of security.
You only need these plugins if the repo were not split into pure-add-on and plus/bleeding/etc. In the latter case you either enable or not the "plus" repo - if you would additionally use any plugin not allowing RHEL upgrades you would not enable a single package in this repo.
Or phrased differently: These plugins effectively try to split such a repo on the fly into pure-add-ons and replacing packages with the latter being turned off. But it is much better to do the splitting at the server-side as you have better control of what needs to go where.
We would first have to decide if we want to allow such replacing packages (it's been a big no-go in Fedora-land), and if we would answer this positively we would have to think whether in one or two repos.
Personally I'm for allowing replacements when needed and placing them (as well as any package depending on that replacement) into the "plus"/whatever repo.
But it depends much on deciding whether we want to have stable API/ABI in EPEL like plain RHEL has.
"MS" == Matthias Saou thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net "TC" == Tom 'spot' Callaway
TC> FWIW, the CentOS people I spoke to at FOSDEM were very TC> much interested in the "fixed set, with bugfixes and TC> security updates only" model.
MS> ...but also in providing a lot of recent stuff. They MS> already have php 5 and mysql 5 in a separate location for MS> people to use on CentOS 4.
I'd say there's a case to be made for different sorts of packages getting updated at different rates. I suspect that where you stand on the issue has a lot to do with the sort of environment that you're in and what set of ``extra'' packages you want to use.
We run CentOS on servers and workstations (used for teaching and doing research). So there are a bunch of things that I package (or grab from RPMForge) that I would like to see up to date for use on the workstations. Most of the stuff on the servers can stay stable (and older), but, on the other hand, there are things that would be nice to keep up to date on servers and workstations (e.g., Subversion).
Where that all gets dicey is when you need to have newer versions of various packages that are part of the base distribution (as with, for example, Subversion).
Claire
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc@math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
On Thu, Mar 01, 2007 at 08:49:02AM -0600, Tom 'spot' Callaway wrote:
On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote:
On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote:
FP! :-)
Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL.
- Do we want a moving (and potentially breaking) set of packages which is constantly being updated?
The CentOS way
- De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
More RHEL like
FWIW, the CentOS people I spoke to at FOSDEM were very much interested in the "fixed set, with bugfixes and security updates only" model.
Well, in the world of clones you usually pick Scientific Linux for point in time releases and CentOS for rolling ones, that's the typical distinction between the last standing major clones. But some recent development will raise a higher incentive to support the RHEL model better within CentOS soon.
But that makes our lives more miserable, because it pushes towards backporting.
On Thursday 01 March 2007 10:18:24 am Axel Thimm wrote:
On Thu, Mar 01, 2007 at 08:49:02AM -0600, Tom 'spot' Callaway wrote:
On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote:
On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote:
FP! :-)
Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL.
- Do we want a moving (and potentially breaking) set of packages
which is constantly being updated?
The CentOS way
- De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
More RHEL like
FWIW, the CentOS people I spoke to at FOSDEM were very much interested in the "fixed set, with bugfixes and security updates only" model.
Well, in the world of clones you usually pick Scientific Linux for point in time releases and CentOS for rolling ones, that's the typical distinction between the last standing major clones. But some recent development will raise a higher incentive to support the RHEL model better within CentOS soon.
But that makes our lives more miserable, because it pushes towards backporting.
Umm CentOS releases updates shortly after RHEL does. Im not sure what rolling releases you are talking about. or are you talking about CentOS plus or some such
On Thu, Mar 01, 2007 at 10:25:29AM -0600, Dennis Gilmore wrote:
On Thursday 01 March 2007 10:18:24 am Axel Thimm wrote:
On Thu, Mar 01, 2007 at 08:49:02AM -0600, Tom 'spot' Callaway wrote:
On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote:
On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote:
FP! :-)
Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL.
- Do we want a moving (and potentially breaking) set of packages
which is constantly being updated?
The CentOS way
- De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on?
More RHEL like
FWIW, the CentOS people I spoke to at FOSDEM were very much interested in the "fixed set, with bugfixes and security updates only" model.
Well, in the world of clones you usually pick Scientific Linux for point in time releases and CentOS for rolling ones, that's the typical distinction between the last standing major clones. But some recent development will raise a higher incentive to support the RHEL model better within CentOS soon.
But that makes our lives more miserable, because it pushes towards backporting.
Umm CentOS releases updates shortly after RHEL does. Im not sure what rolling releases you are talking about.
Roling in the sense of the minor release integer.
or are you talking about CentOS plus or some such
No, that's something different, that's an add-on repo which goes beyond cloning.
Compare
http://isoredirect.centos.org/centos/4/isos/i386/
to
https://www.scientificlinux.org/download/
E.g. the range of 4.x versions. SL follows RH in maintaining each point release, while CentOS kind of EOLs the previous point releases.
Axel Thimm wrote:
On Thu, Mar 01, 2007 at 10:25:29AM -0600, Dennis Gilmore wrote:
Umm CentOS releases updates shortly after RHEL does. Im not sure what rolling releases you are talking about.
Roling in the sense of the minor release integer.
Compare
http://isoredirect.centos.org/centos/4/isos/i386/
to
https://www.scientificlinux.org/download/
E.g. the range of 4.x versions. SL follows RH in maintaining each point release, while CentOS kind of EOLs the previous point releases.
Ummm. No. I don't think RH still maintains 4. Or 4U1. Or 4U2. So we don't either. All updates are going against the latest (misnomed) 'quarterly' update. And I don't think that SL does it any different, although I might be wrong there. Because every quarterly update is a big update set against the previous one (including updates).
So I'm not too sure about what you are talking about.
Cheers,
Ralph
Ralph Angenendt wrote:
Ummm. No. I don't think RH still maintains 4. Or 4U1. Or 4U2. So we don't either. All updates are going against the latest (misnomed) 'quarterly' update. And I don't think that SL does it any different, although I might be wrong there. Because every quarterly update is a big update set against the previous one (including updates).
So I'm not too sure about what you are talking about.
Cheers,
This is something we can change later. Lets keep it simple for now and if an issue comes up we can discuss it as a real example instead of guessing what problems will come up. The releases are just a snapshot of the rolling updates at some point in time. Its pretty arbitrary AFAIK.
-Mike
On Tue, Mar 06, 2007 at 04:50:13PM +0100, Ralph Angenendt wrote:
Axel Thimm wrote:
On Thu, Mar 01, 2007 at 10:25:29AM -0600, Dennis Gilmore wrote:
Umm CentOS releases updates shortly after RHEL does. Im not sure what rolling releases you are talking about.
Roling in the sense of the minor release integer.
Compare
http://isoredirect.centos.org/centos/4/isos/i386/
to
https://www.scientificlinux.org/download/
E.g. the range of 4.x versions. SL follows RH in maintaining each point release, while CentOS kind of EOLs the previous point releases.
Ummm. No. I don't think RH still maintains 4. Or 4U1. Or 4U2. So we don't either.
I'll better let someone with a Red Hat on answer this in detail, but I know that this doesn't hold true (anymore). Maybe only for selected releases (and I hope not only for selected clients).
On 3/6/07, Ralph Angenendt ra+redhat@strg-alt-entf.org wrote:
Axel Thimm wrote:
On Thu, Mar 01, 2007 at 10:25:29AM -0600, Dennis Gilmore wrote:
Umm CentOS releases updates shortly after RHEL does. Im not sure what rolling releases you are talking about.
Roling in the sense of the minor release integer.
Compare
http://isoredirect.centos.org/centos/4/isos/i386/
to
https://www.scientificlinux.org/download/
E.g. the range of 4.x versions. SL follows RH in maintaining each point release, while CentOS kind of EOLs the previous point releases.
Ummm. No. I don't think RH still maintains 4. Or 4U1. Or 4U2. So we don't either. All updates are going against the latest (misnomed) 'quarterly' update. And I don't think that SL does it any different, although I might be wrong there. Because every quarterly update is a big update set against the previous one (including updates).
Yes Red Hat ONLY supports the latest version of its product until 4.5.0 is released. At that point they will be moving to a newer support paradigm similar to the Scientific Linux. Basically if I am understanding things correctly.. 4.5.1 will be security updates only to 4.5.0 and not enhancement additions. 5.0.1 will be the same.
They will also not be back-supporting 4U1->4U4. Only 4.5.0,4.6.0, and maybe if they have a 4.7.0 is going to be generally maintained as this.
epel-devel@lists.fedoraproject.org
-
Axel Thimm -
Bill Nottingham -
C.M. Connelly -
Dennis Gilmore -
Karsten Wade -
Matthias Saou -
Michael Stahnke -
Mike McGrath -
Ralph Angenendt -
Rex Dieter -
Russell Harrison -
Stephen John Smoogen -
Thorsten Leemhuis -
Tom Callaway