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 ;-)
> 1. Recent emails to the "-dev" list have identified various problems in
> the code, and Lars M-B has suggested on a few occasions that janitorial
> work on the code would be welcome.
Well, yes. But, I have to admit it's one of my pet peeves. I'm not
working on any given piece in particular, and not even doing much coding
these days, but I'm very often asked to dive in and understand
something, or I try to do a reasonable job of reviewing the code as it's
committed.
And then the lack of coherency, varying coding styles and even code
formatting really, really starts to get on my nerves. And so I begin
cheering everyone on who starts cleaning up things ;-)
Consider all observations I didn't quote ack'ed.
> 5. A colleague here (Andrew Stribblehill) and I have long had a gut
> feeling (instinct, etc.) that the overall code base just feels too big.
> (Put another way: if the supplier were Microsoft, the word "bloat" would
> be surfacing!) There's a vast amount of code: but what does it all
> actually, really, ultimately do? And does it do it in a "best practice"
> manner or only in a "get the job done" manner?
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 ;-)
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.
> 6. Et cetera.
Wiki, project planning, and bugzilla are sort-of the same category.
> 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.)
And also, incremental changes are easier to review, I hope.
My personal policy suggestion would be to not only refactor the code,
but to first write a testcase, refactor the code, re-run the testcase.
Not only will this result in more confidence that the code works, but it
also will give us a testcase, and _writing_ the testcase will help
whoever rewrites the code understand what it was doing.
(Mere coding style cleanups of course might be exempt from such a
policy; apply your own common sense.)
> 3. (Another deep breath...) Is "python" now an essential pre-requisite for
> heartbeat?
It probably is, yes.
> 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.
Now, I'd agree that this implies that they are good targets for close
scrutiny and should also be obvious to understand.
Python might be a candidate for more complex resource agents, though.
> 4. By doing such exercises, it might make future developments actually
> easier (short-term pain; long-term gain). For instance, writing a module
> or daemon in "python" (or into a python framework) might be easier than
> doing it in C, especially given the large amount of string handling that
> often has to be done.
Again, keep in mind that while we're in user-space, we must operate
under fairly tight constraints. I don't see anything in the core which
would be a good candidate for python.
> Might this suggest a transition from "2.0.x" to (say) "2.2.x"? The 2.2.0
> branch would be functionally equivalent to 2.0.7, but tidied as above.
No, I don't think this is good. If it is functionally equivalent, we
ought to take the extra effort and feed the cleanup into the regular
cycle.
The _how_ is probably the only thing I disagree with; all your
suggestions (except being slightly over-enthusiastic about python ;-)
are good.
Sincerely,
Lars Marowsky-Brée
--
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/
