On 2006-08-16T16:07:10, Alan Robertson <[EMAIL PROTECTED]> wrote:
> > That's not discrediting your opinion in this regard, If your scope is
> > Heartbeat, then, why, that's the obvious (and correct!) answer.
>
> The project's scope is by definition "heartbeat". Since this is a
> vendor-neutral project (and even OS-neutral), it is an error to assume
> that we can fix everything upstream in a timely fashion.
These comments probably were true for bugs in proprietary operating
systems.
We're also part of the open source ecosystem as a whole. It isn't our
responsibility to work-around every possible known bug in other
libraries we're using. This leads to coding ballast which we shouldn't
carry on. I believe this is a code cleanliness and overall
maintainability of the system.
If someone wants to package heartbeat for a broken distribution, they
ought to apply the work-around patch themselves. The main code base
should focus on non-broken platforms, and push the responsibility for
fixing bugs where they belong.
It's not this specific kludge I'm opposed to, but the general attitude
behind it - "it works" is _not_ the sole criteria for code to me.
These are my beliefs, and what I believe and think to be sound
engineering practice in an Open Source project. And also commonly shared
by many Open Source projects (such as, for example, the Linux Kernel -
many patches have been rejected, even though they did implement some
functionality, but because they weren't acceptable in style and
design).
This is obviously a point where we choose to disagree, and from which
the rest of this discussion stems. It is only technical in as far as it
leads us to judge the merits of a particular technical detail, but
beyond that, I'm afraid it comes down to aesthetics.
As we're not going to make any progress on this fundamental
disagreement, I'll end this discussion here.
Just a few tangential notes:
> A proper analogy is to say that certain BIOS calls are broken, so Linux
> should go on and not work on any existing system because it's broken on
> every system.
"Your BIOS is broken, get an update or complain to your vendor, RESOLVED
INVALID" is a wide-spread (and belived to be correct) response to
certain classes of bug reports, even when reported by large customers or
partners.
Not only does it lead to cleaner code locally, but it also creates
pressure on the broken party to get it fixed (and speed up the roll-out
process), and so improves over-all quality.
_But_, what's more important: ACPI, BIOS et cetera issues live outside
the OSS eco-system, which is a fundamental distinction.
(If the Linux kernel developers could tell one to patch their ACPI
tables instead of applying a work-around in the kernel, it's what they'd
do.)
So, this is at least comparing apples to oranges.
> FYI: This bug is blocked from public access, and for access from me, for
> that matter.
Oh, ok. I've reported it against SLES9, which is non-public by default.
Oh well. I've added you to the Cc list for now.
Sincerely,
Lars
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
