For Linux, no doubt about RHCE. For Unix in general, including Linux and focused on Security, go to <a href="http://www.giac.org">www.giac.org</a> (GCUX).<br><br>Regards<br><br>-- <br>Alexandre Teixeira<br><a href="http://www.linkedin.com/in/inode">http://www.linkedin.com/in/inode</a><br>
<br><div class="gmail_quote">2009/7/1 Joel Bernstein <span dir="ltr"><<a href="mailto:joel@fysh.org">joel@fysh.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
On 1 Jul 2009, at 15:56, Richard Jones wrote:<br>
<br>
> On Wed, Jul 01, 2009 at 03:03:51PM +0100, Joel Bernstein wrote:<br>
>> As a customer I'd also want to know that the processes had been<br>
>> improved to prevent a repeat, though.<br>
><br>
> If you are a customer (I have no idea if you are or not) then you can<br>
> ask about this through support, where they will be happy to explain<br>
> the large amount of internal QA and package-to-package comparisons<br>
> that we perform on everything before it goes out.  Also our ISO-<br>
> compliant processes.<br>
<br>
</div>I don't understand this. The processes failed. No matter their<br>
buzzword compliance. Were they radically improved to prevent a single<br>
maintainer from buggering things up for everybody again? It seems an<br>
appalling, heinous lapse. Have I got this wrong?<br>
<div class="im"><br>
> I don't know of any software engineering organization that has<br>
> completely eliminated all bugs from every piece of software they<br>
> release.  At least, not for a price that you or I are willing to pay.<br>
<br>
</div>You seem to ignore the fact that this was a problem _created_ by Red<br>
Hat. Admittedly, the Perl repo should be run in a manner whereby it<br>
builds after every commit, but RH's Perl maintainer ought to have<br>
known that it isn't always in a releasable state. Nobody else took<br>
such a cavalier "we lead and you follow" attitude with it. This isn't<br>
by any means a "developers shouldn't write buggy code" issue, it's one<br>
of poor maintenance - poor by the standards of a niche free distro,<br>
not a supposedly industry-standard expensive commercial one.<br>
<br>
Richard, I appreciate your corrections where due and I understand you<br>
sticking up for your employers but seriously -- do you think this was<br>
a well-handled issue? Was it one that occurred through reasonable<br>
causes? Fundamentally, isn't it one that is likely to happen again if<br>
the processes didn't change? That's my issue here. I'd much rather /<br>
not/ have to tell my clients to build their own Perl or run my code on<br>
a different distro / OS.<br>
<br>
Somewhere, deep down, it feels a bit wrong to couple dependencies for<br>
a fast-moving application with the system utilities' dependencies. So<br>
on a distro with lots of tools/commands/scripts in Perl, which have to<br>
keep working, I'd lean somewhat away from installing my own up to date<br>
dependencies on the system Perl. But that's more a matter of taste and<br>
cuts right across any distro-specific prejudice. Any thoughts on that?<br>
<font color="#888888"><br>
/joel<br>
</font><div><div></div><div class="h5">--<br>
Gllug mailing list  -  <a href="mailto:Gllug@gllug.org.uk">Gllug@gllug.org.uk</a><br>
<a href="http://lists.gllug.org.uk/mailman/listinfo/gllug" target="_blank">http://lists.gllug.org.uk/mailman/listinfo/gllug</a><br>
</div></div></blockquote></div><br><br clear="all"><br><br>