meillo wrote: > Hmm that's then the basic point where we differ. I do care if the > inside is clean and I rather like to remove features than add ones. > From my point of view these are key factors to maintainability and > thus for the future of the code. One of the most important properties > of software is the question if the concepts are most simple and > implemented best possible. If at some time the concepts are found to > be imperfect, I really favor for change.
> I admit that providing a drop-in replacement is a fully valid goal. I > rather dislike the fact that this looking back holds us from going > forward. (It's more a general problem, though.) Then it's time to fork. Especially given that the current code base has changed surprisingly (to me) little in the last decade or so. It might not be pretty but it works, at least well enough to get used often. While maintenance is painful, that doesn't happen very often. And the intricate dependencies of people and frontends on nmh restrict the kinds of changes that can reasonably be made. For example, while I don't use many, or even most, of nmh's features, I think it would be a really bad idea to remove any of them. I could see an argument for starting over from scratch, but it's clear that not enough people have enough spare time for that. Another data point: I use nmh exclusively as my MUA. Also, I haven't used mhbuild (mime at the whatnow prompt) since I started using -attach. It's very easy to use and it certainly does work well. David ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers