Jos Vos wrote: > Maybe, but only as a conulting service, completely independent from > the RHEL development team, I'd guess.
In addition to the TAM service: http://www.redhat.com/support/policy/soc/tam/ There is Custom Engineering services: http://www.redhat.com/services/custom/ As I have stressed many times before, these are things to ask your sales representative and/or solutions architect about. Because ... Laszlo Beres wrote: > My question was about it, for the first sight RH just simply refused to do so. Red Hat support will often refuse, because they are under Service Level Agreements (SLA). Hence, again, leverage your sales person and/or solutions architect. Jos Vos wrote: > This kind of "extras" is typically done by Red Hat partners, who have > the detailed knowledge of the customer and can make the proper > (local) arrangements. Actually, that's why Red Hat offers the TAM, because they will be dedicated to the customer environment. Jos Vos wrote: > We have similar situations with customers, where we support other versions > of packages or packages not existing in RHEL for them, in addition to their > RHEL subscription. In many cases, these are where the ISV partner agreements come in. Although I haven't been involved with a Red Hat customer where the TAM became the focal point for not just the platform/middleware provide by Red Hat, but the ISV and added software as well. James Harrison wrote: > If you need the latest software versions why not use Fedora? Laszlo Beres wrote: > You can't ask this seriously. Why not? Even Extra Packages for Enterprise Linux (EPEL) falls under the Fedora(TM) Project. Just because the Fedora distribution is not a "product" does not mean it is not enterprise deployed. Fedora(TM) is the community branding of Red Hat(R). The Fedora distribution itself is development exactly the same as Red Hat(R) Linux before it, right down to unit, integration and regression testing. If you rotate systems every year, it can be the ideal solution when you need leading edge. It's these types of conversations that one should be having with sales and solution architects -- let alone TAMs if you already have one. Laszlo Beres wrote: > We use RHEL because we like its stability, scalability, quality. But > sometimes there comes a need to provide X or Y service, functionality > and we cannot do this with a few default application versions. Sure we > could say "RHEL is not the best base system in this case, go ahead > with A, B, C operating systems", but we don't want to do that. The problem with newer features in other options is that they don't go through the full cycle of not just unit and integration testing, but regression avoidance. Based on our off-list correspondence, what you wish would introduce an incompatibility with existing software, which is what people buy Red Hat subscriptions to avoid. Rebasing of software is done very sparing in Red Hat products for this reason. _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
