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. > Now, I'd agree that this implies that they are good targets for close > scrutiny and should also be obvious to understand. Yes, please! > > > 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. OK. Fair enough. Just kite-flying... > > The _how_ is probably the only thing I disagree with; all your > suggestions (except being slightly over-enthusiastic about python ;-) > are good. My only reasons for suggesting python was that we already use it, and that the rewrite would prompt a rethink about structure which ought (ideally) to produce a cleaner, more maintainable result. (Also, C code often introduces things that work on one system/OS/compiler but fails on others (python less suscetible to this). And C functions that have to do string processing and error/exception handling are a lot more complex than equivalent python code.) All the best. -- : 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/
