On Thu, Aug 10, 2006 at 06:01:48PM +0100, David Lee wrote:
> 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?
Not sure about the code quality, but given the set of features
provided, I'd expect the code to grow considerably.
> 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.
Python is used only for GUI and CTS. I'm not sure if it would be
the right way to switch to a scripting language for critical
things such as resource manager. Besides, my gut feeling is
that just choosing a different language won't improve the code.
Other factors are more important. However, if a peace of code is
bad, it's typically better to start from scratch. But that
shouldn't imply changing the language.
> 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.
Hmm, what's wrong with criticism? Hopefully, people here can take
criticism.
> OK. Give me a couple of minutes to don a full fire-retardant suit...
Why, I think that this initiative is good and probably necessary.
A project like Heartbeat demands higher standards than most.
Cheers,
Dejan
>
>
>
> --
>
> : 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/
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
