Release and update procedure for EPEL

[Thorsten Leemhuis]

Axel Thimm schrieb:
> On Fri, Mar 02, 2007 at 06:44:50PM +0100, Thorsten Leemhuis wrote:
>> Bill Nottingham schrieb:
>>> Thorsten Leemhuis (fedora at 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