[Gllug] Red Hat versus other qualifications

Alexandre Teixeira alexandre.abreu at gmail.com
Wed Jul 1 16:59:49 UTC 2009


For Linux, no doubt about RHCE. For Unix in general, including Linux and
focused on Security, go to www.giac.org (GCUX).

Regards

-- 
Alexandre Teixeira
http://www.linkedin.com/in/inode

2009/7/1 Joel Bernstein <joel at fysh.org>

>
> On 1 Jul 2009, at 15:56, Richard Jones wrote:
>
> > On Wed, Jul 01, 2009 at 03:03:51PM +0100, Joel Bernstein wrote:
> >> As a customer I'd also want to know that the processes had been
> >> improved to prevent a repeat, though.
> >
> > If you are a customer (I have no idea if you are or not) then you can
> > ask about this through support, where they will be happy to explain
> > the large amount of internal QA and package-to-package comparisons
> > that we perform on everything before it goes out.  Also our ISO-
> > compliant processes.
>
> I don't understand this. The processes failed. No matter their
> buzzword compliance. Were they radically improved to prevent a single
> maintainer from buggering things up for everybody again? It seems an
> appalling, heinous lapse. Have I got this wrong?
>
> > I don't know of any software engineering organization that has
> > completely eliminated all bugs from every piece of software they
> > release.  At least, not for a price that you or I are willing to pay.
>
> You seem to ignore the fact that this was a problem _created_ by Red
> Hat. Admittedly, the Perl repo should be run in a manner whereby it
> builds after every commit, but RH's Perl maintainer ought to have
> known that it isn't always in a releasable state. Nobody else took
> such a cavalier "we lead and you follow" attitude with it. This isn't
> by any means a "developers shouldn't write buggy code" issue, it's one
> of poor maintenance - poor by the standards of a niche free distro,
> not a supposedly industry-standard expensive commercial one.
>
> Richard, I appreciate your corrections where due and I understand you
> sticking up for your employers but seriously -- do you think this was
> a well-handled issue? Was it one that occurred through reasonable
> causes? Fundamentally, isn't it one that is likely to happen again if
> the processes didn't change? That's my issue here. I'd much rather /
> not/ have to tell my clients to build their own Perl or run my code on
> a different distro / OS.
>
> Somewhere, deep down, it feels a bit wrong to couple dependencies for
> a fast-moving application with the system utilities' dependencies. So
> on a distro with lots of tools/commands/scripts in Perl, which have to
> keep working, I'd lean somewhat away from installing my own up to date
> dependencies on the system Perl. But that's more a matter of taste and
> cuts right across any distro-specific prejudice. Any thoughts on that?
>
> /joel
> --
> Gllug mailing list  -  Gllug at gllug.org.uk
> http://lists.gllug.org.uk/mailman/listinfo/gllug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20090701/0796c4b4/attachment.html>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug


More information about the GLLUG mailing list