[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Holiday hacking project: nmh?

From: Chad Walstrom
Subject: Re: [Nmh-workers] Holiday hacking project: nmh?
Date: Sun, 10 Oct 2004 16:37:00 -0500
User-agent: Mutt/1.5.6+20040722i

address@hidden wrote:
> I encounter bugs in mh that no-one seems to want to acknowledge or
> want to fix.  Also I strongly suspect that many security bugs lie
> within the ancient mh code, and the attitude of many is apathy.

nmh is an old code-base, well established, and stable.  Stable things
don't generally get messed with unless there are bugs or security
problems.  You've found some bugs, so go ahead and fix them.  This
environment is all about scratching itches.  If you have an itch,
scratch it and tell people how you did so.

> My own little attempt to help give nmh a little nudge (the suggestion
> of a distributed version control system) was not met with enthusiasm.

Again stability, even in a development environment, does not work well
with change.  Changing the version control system does not improve the
software.  It only makes it more convenient or more fun for you to work
with.  I do the same thing with my own local repositories of FOSS, but I
don't try to force changes upstream unless there is an overwhelming
agreement to do so amongst the active contributing developers.   Don't
expect everyone to jump the bandwagon to try the next greatest fad in
development environments.  Your nudge wasn't really a nudge.

> My own pie in the sky thoughts would be towards replacing some of the
> code with some better tested or more widely used mail handling code,
> (librfc822 ? (1)) and also possible partial conversion to c++.

That would be a pie, wouldn't it.  IMHO, converting a stable code-base
to C++, even partial, is introducing unnecessary complexity to the build
environment and requires your developers to learn yet another language,
however similar it may be.  Everyone has a favorite language to work
with, but that it does not necessitate migrating a proven product.

With respect to librfc822, it is licensed under GNU GPL.  This may not
be a problem for someone making a derivative of nmh, a fork.  To get
librfc822 incorporated into nmh proper, however, you would be required
to receive approval from all of the contributing authors to release the
modified nmh with the new license, GNU GPL.

Sometimes change is useful, and sometimes its unnecessary.  Refactor
rather than re-engineer.

Chad Walstrom <address@hidden>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]