On Tue, 2007-07-31 at 17:54 +0300, Manuel Wolfshant wrote:
> Sorry to contradict you, but you are not fair. The attitude in major 3rd
> party repos is far from "oh, it built".
I specifically said "select RPMForge/3rd Party repositories".
^^^^^^
I *DO* give kudos to _several_ RPMForge/3rd Party repositories when it
is due. That's why I said "select". _Remember_ my context here, RHEL
with optional SLAs. ;)
But there *ARE* _several_ ones that do not want to deal with Red
Hat/Fedora processes. They were quite critical of them when Fedora
Extras first started up. I was rather disgusted at the "attitudes" they
had towards Red Hat's "requirements" on Fedora Extras, because it was
about ensuring some basic level of integration testing, not just "a
package dump."
> I am constantly using several of them (especially rpmforge, sometimes
> atrpms, centosplus and kb)
First off, I have _nothing_ negative to say about "CentOS Plus" (some of
the more "fringe" CentOS stuff is another story though -- thank God for
EPEL ;).
Secondly, I use ATrpms myself too.
But, third, I do _not_ put _either_ of them in my YUM repo.d blindly.
If I do, I pigeon-hole them for _specific_ RPMs (e.g., madwifi).
Which all goes to ... fourth ... I wouldn't like the idea of doing a
RHEL update at a client under SLA contract when they have various EPEL
packages installed (much less RPMForge/3rd Party).
> And the quality of specs for many of the packages in those
> repositories is lots of times excellent.
A SPEC file might be well designed (and I *DO* like RPMForge for that --
good "peer support"), but that doesn't mean the end product is still
well integration tested. ;)
In other words, when I tap a SPEC file, I don't merely just "build and
release." I actually do an integration and regression test.
There is a reason why Red Hat backports fixes for RHEL packages. Are
EPEL maintainers going to do the same to guarantee 7 years for complete
ABI/API compatibility?
Microsoft constantly harps on the reality that independent software
quality is one thing, but integration and regression testing is another.
They are correct. At the same time, their statements are rather
self-defeating when you start comparing Windows Professional or Server
to RHEL/RHD -- because you get both individual software quality combined
with integration and regression testing and a massive effort to ensure
long-term ABI/API compatibility to an anal power.
[ SIDE NOTE: The key to combating Microsoft FUD is not to call their
statements lies, but to explain them. In the overwhelming majority of
cases, their own FUD is their worst enemy. ]
> I know I repeat myself, but axel, dag,dries, hughes jr, karanbir,and thias
> (alphabetically listed) do a great job and I am once again happy to
> extend my thanks to them for their work.
Sigh ... I'm _so_tired_ of seeing my words twisted into things they are
_not_. No offense, but since some people don't seem to "get it" ...
1. I didn't build my consulting rep on just "oh, I got this package and
it works!" At the same time ...
2. Just because I don't put Axel, DAG, Dries, etc... in my default YUM
repos does *NOT* mean I don't think they are excellent resources or use
them regularly.
*PLEASE* stop reading into my statements!
> EPEL is just an effort to bring in the RHEL world the packages from the
> former Fedora Extras while also trying to the best of our (I speak now
> as a Fedora Collection maintainer and as a member of EPEL SIG )
> abilities to also respect the long term commitment of RHEL (in terms of
> ABI etc).
And I _do_ appreciate that. But there is a "line to be drawn."
At some point, the "convenience" of putting EPEL in as a "default
repository" in RHEL might also be a _burden_ on Red Hat, its consultants
and those who implement its SLA guarantees. ;)
That's _all_ I was pointing out. Sigh. I guess I just spent too many
years in defense and aerospace systems. ;)
--
Bryan J. Smith Professional, Technical Annoyance
mailto:b.j.smith@xxxxxxxx http://thebs413.blogspot.com
--------------------------------------------------------
Fission Power: An Inconvenient Solution
--
Fedora-marketing-list mailing list
Fedora-marketing-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-marketing-list
