[nSLUG] Improving QA of Linux distributions

D G Teed donald.teed at gmail.com
Fri Jun 24 12:36:54 ADT 2011


On Thu, Jun 23, 2011 at 2:01 PM, Ben Armstrong
<synrg at sanctuary.nslug.ns.ca>wrote:

> On 06/23/2011 12:14 PM, D G Teed wrote:
>
> > I've had experiences demonstrating poor coding practise of
> > the elementary sort  (e.g. test for a file before opening, or
> > catch the error when the file doesn't exist).  There are times
> > they could be doing way better (don't worry, it wasn't Debian).
>
> Doesn't matter if it were Debian. Yes, it happens sometimes. Quality of
> contributions is not uniform across Debian. Nor is there any way of
> mandating that in a large, volunteer-run organization such as ours.
>

Understandable in one sense, but overall Debian does try to pick good
quality contributors, who have demonstrated the capability before hand.

I would think everyone who is writing code (say at Redhat, in this case
of not testing for a file before opening) is aware of things they teach in
a first year programming course.  Maybe it is simply taking shortcuts -
tends to happen in anything people do fast. One can spend the time
writing the code with tests all the way through, with an error
like "this shouldn't happen" for something you are certain will
never happen (one coder I knew used to use "oh shit!"
when he was confident the test should always fail - this was for a
commercial
product used by Fortune 500, military and government.).  If one does
that seemingly pointless error catching for a number of years, perhaps the
shortcut can be to leave it out.  Just a speculation.  Or the Redhat coder
doesn't
have first year programming knowledge, which would surprise me.


>
> > I'd call it minimal efforts to get it working and then
> > chalk up a success.
>
> A fair portrayal for isolated cases. Fortunately there are checks and
> balances in the Debian ecosystem (a rigorous policy document and a
> lengthy and thorough release process where such things are mopped up
> before the release is made, for instance).
>
> Where I take exception is your tendency to over-generalize about this
> problem. You seem to paint all of open source development with the same
> brush.
>

Well, you have not seen the nasty things I have to say about some commercial
software vendors.  There is one vendor used by many Universities for the ERP
systems which sometimes reissues newer patches with the same identifier.
Completely insane and unheard of anywhere else I've seen.  But this mailing
list
isn't the place to talk about them.

I guess my expectations are high for open source projects, especially core
ones.
I would think this many years mature there should be less reason
to make disruptive modifications in the kernel and boot loader.
I've seen hardware compatibility issues with 7 year old IBM server
equipment.
Eventually found a workaround, but there was downtime I've never had before
from Debian in situ upgrade. Redhat 6 CDROM (for 32 bit) fails to find the
install
media (even in VMware).

Some responses I get back (other mailing lists) say I should use newer
systems
or those which have a DVD drive.  I've never seen this happen before.
Linux used to be good to run all the way down to the 386 in the late 90's.
Things will be more difficult for users, such as those in the developing
world
where they can't afford to buy servers less than 4 years old and
virtualization is
years away from being thinkable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nslug.ns.ca/mailman/private/nslug/attachments/20110624/8c713d9e/attachment-0002.html>


More information about the nSLUG mailing list