This is intended merely as a set of random thoughts. No criticism is
intended! Honestly.
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.
2. My own minor dabblings at various places across the code (mainly to try
to pin down Solaris-driven problems and to try to rectify them in an
OS-independent manner) have identified various places where the code makes
assumptions (unintentional, I'm sure) about the environment (e.g. sh/bash)
and is inconsistent in naming relocatable directories ("HA_VAR*" etc.).
3. Bugs lurk on non-Linux implementations. We still don't pass BSC on
non-Linux systems (Solaris, BSD). Why? What features of the coding cause
these failures?
4. Debugging for an outsider (such as me) is a headache: for one thing the
internal documentation and commenting is lacking in too many places.
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?
6. Et cetera.
Heartbeat started small, with various ideas. It has grown; the ideas and
visions have changed. Time has moved on and the typical OS environment
has widened.
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.)
Just a few examples that spring to mind (at various different levels):
1. IPaddr and IPaddr2: We shouldn't really be offering the end-user two
options. We ought to be able to offer one product which "does the right
thing".
2. "HA_VAR*" inconsistencies: Sweep through and tidy these up. Includes
removal of "-DHA_*=*" from all "Makefile.am", all of which can now be
removed (with a few essential renames in various ".h" and ".c" files).
3. (Another deep breath...) Is "python" now an essential pre-requisite for
heartbeat? If so, should various things (e.g. "lrmd" and friends,
"stonithd" and friends) be rewritten into python? They would almost
certainly become significantly smaller and thus cleaner and easier to
understand, to maintain and to document. The very act of such a rewrite
(from one language type to a very different type) would itself result in
tidying by concentrating the mind on intended functionality.
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.
5. Insert your own pet "I wish {X|Y|Z} were {tidier|maintainable}" here.
6. Et cetera.
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.
Doubtless such work feels tedious and uninviting for development-minded
folk. But I still think we ought at least to entertain the thought, even
if only to the extent of generating defensible reasons not to do it.
As I say, simply "blue sky wish-list", and probably with rose-tinted
spectacles. (Might "blue sky" through "rose tint" get a bit dark??)
Let me repeat that this is not intended as criticism. Please, please
don't take it as such.
OK. Give me a couple of minutes to don a full fire-retardant suit...
--
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: Durham University :
: http://www.dur.ac.uk/t.d.lee/ South Road :
: Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
