David Lee wrote:
> On Fri, 11 Aug 2006, Lars Marowsky-Bree wrote:
>
>> On 2006-08-10T18:01:48, David Lee <[EMAIL PROTECTED]> wrote:
>>
>>> This is intended merely as a set of random thoughts. No criticism is
>>> intended! Honestly.
>> Constructively noted ;-)
>
> Thanks for the reply!
>
>> [...]
>> True. We have a number of unmaintained features in the code: SNMP, the
>> telecom stuff, tipc comm plugin, to name the just some offenders. Some
>> of these probably don't even work nowadays.
>>
>> In the Linux kernel, this sort of bitrot gets only compiled in when
>> CONFIG_BROKEN is set. I like that approach, but even better, I'd like to
>> rip it out ;-)
>> [...]
>
> +1 for the rip-out. CVS (and its successors) should be robust enough for
> any occasional necessary "oops! un-rip" operations.
>
> Perhaps you should begin this almost as soon as 2.0.7 ships. Then folk
> here on this list will have plenty of time to stumble across any of those
> occasional "un-rip" requirements.
>
>> Now, the main criteria for accepting a patch has so far - no offense
>> intended, really! - whether it works, not whether it is in good style or
>> design. (ie, some of the Resource Agents or plugins.) As we have come to
>> rely on these features, we can't simply drop them.
>>
>> But, we can clean up what's there and start enforcing stricter rules for
>> newly submitted code.
>>
>> We've not been very good on following policies in the past, but maybe we
>> can do better in the future.
>
> I suspect that when the first, rough draft of a new, experimental module
> goes in, it doesn't get seriously peer-reviewed. That's understandable...
> it is a first, rough draft. Any peer review tends to kick in only later,
> by which time any overall poor design (include opaque structure and
> spaghetti code) is too deeply embedded, and that peer-review is only
> focussed on the particular detail, not the "big picture".
>
>>> So (deep breath! ...) once 2.0.7 is shipped, might it be time to pause and
>>> take stock? We would continue the background bug-fixing as always, but
>>> for a while would put a hold on new developments, and instead do some sort
>>> of audit and rationalising of the code and its documentation. (Yes, I did
>>> present that as a (mostly) "either/or" thing because realistically I think
>>> that is what we would need to do.)
>> My main comment: This doesn't tend to work. We need to weave in the
>> cleanups with the new features as we go along.
>>
>> The Linux kernel shows that incremental improvements work, as do other
>> projects.
>>
>> That's not to say that we can't do this for one component in a go - I
>> assume we can readily swing a rewrite of, say, IPaddr, or some library,
>> et cetera. But we can't do this for the whole project in one go. We need
>> to refactor in manageable steps.
>>
>> (Frankly, I now must put on my pointy hair, and mention that freezing
>> development essentially completely for the time needed to clean up the
>> whole codebase is simply not going to fly for Novell/SUSE and I guess
>> neither for IBM. Incremental changes are a must.)
>
> OK. I was simply floating a kite. It probably deserves to be sunk.
> Fair enough.
>
>>> If so, should various things (e.g. "lrmd" and friends, "stonithd" and
>>> friends) be rewritten into python?
>> Alas, these are not good targets. lrmd, stonithd and friends are
>> intrinsic to our operation, remain locked in memory, and in effect, must
>> be as deadlock-free & not block on disk-IO etc as possible. This is
>> harder to do in a scripting language than it is in C.
>
> OK. I had recently been attempting to look into "lrmd" to understand a
> problem and finding it impossible to get to grips with. So, from a purely
> programming-style view point, I had suggested this as a candidate for
> possible re-write into a completely different language, as it just might
> possibly result in a better product. But the additional considerations
> you mention almost certainly block that idea.
The LRMD is child's play to read when compared to most of the rest of R2.
People have actually read the lrmd and understand it. I didn't say I
like the code, but I do understand it.
If there's a piece of code that really needs scrutiny I'd start with the
least-reviewed, most complex piece of code - or if you prefer, the one
with the most bugs in the last 6 months or so.
Or maybe you'd prefer the piece of code with the most changes.
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
