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

Re: RHN software channels & EPEL

Thorsten Leemhuis wrote:

Exactly. Not having some libs just because some layered product ships
them as well could be problematic for EPEL and hurt it a lot.

In this talk to Daniel Riek and see if it feasible to add that library to the base product. It won't happen immediately. New packages are added only when required in the sync updates which was previously quarterly and still somewhat follows that schedule.

Even then some customers consider the changes in between these updates large and stick with a older version (ie) 4.2 though 4.4 has been released and Red Hat has announced recently a separate support and updates stream for that case so packages added in the later revisions will be excluded for them. As you can imagine there is a lot of complexity in managing all these but you can probably ignore this case since customers using this update stream are highly sensitive to changes and are unlikely to just pull in packages from any external source without commercial support guarantees.

I'm unsure myself about this one. A *short* version and just a fragment
of the thoughts in my head: people pay Red Hat for the support, but some
people might just want the support for the OS, but not for a specific
software they install. Should we try to force those people into the
existing model (users nevertheless can just rebuild the Fedora-DS or
RHEL-DS SRPM) or do we simply offer what we have and let them chose if
they want payed support or not?

I am all in for providing more flexibility here but I don't really want to create more support pains. Since the base product that we are complimenting has support has one of the core values this has a high priority.


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