[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Release and update procedure for EPEL



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?
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpKiZcY8LHMr.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]