our relationship is a bit special. I came in February and it
resulted in a big discussion on MTAs and the like. I came again
recently, had been active, proposed improvements, but feel like
running agains walls.
The point is, we collide at any point. It's the community on the one
side and me on the other. At least this is how it feels to me. I
realize that my opinions and point of view is quite different from
your's (at least of those who speak up).
I trust that all opinions expressed on the issues have been
based on good reason and intent. Please don't feel that any
sides are being taken, especially against an individual.
Suggestions for improvements are always welcome by me, and
by others from what I've observed here.
The main topic of our disagreement is compatibility.
As I'm sure you're aware, many of us have been using mh/nmh
for a very long time (decades!). Whatever its deficiencies,
it works. Furthermore, I use nmh a _lot_. So compatibility
is quite critical.
It seems to me as if you would be doing compatibility for
compatibility's sake. This is sticking to old cruft. Caring to much
for some old userbase likely keep you from getting new users while old
ones slowly vanish. This also includes frontends. It is a dead end.
If it's old cruft that works, I'm happy to stick to it. If
anyone wants to fix things under the hood, without breaking
anything, or add new capabilities, great!
I value clearer and simpler solutions above compatibility in any case.
I understand the importance for compatibility in case of a backend,
but it should never be for it's own sake, but this is what I feel here
again and again.
Is nmh just good enough for you and therefore better not changed? Is
updating your setups once a year more effort than the improvements of
modernization? It could be and I would understand. The point is:
What is the goal of nmh?
At this point, compatibility has got to be part of nmh's goal.
It was even at its inception, according to docs/README.about:
"intended to be a (mostly) compatible drop-in replacement for MH"
That's what I don't understand. No matter what I try to do, I conflict
with you. This indicates that we probably have too different views of
With pleasure I see the discussion of nmh2 which could finally be a
step in my direction. But before I cheer too much up, I'd better know:
What's the goal for nmh2, if it should come to happen?
Good question. I think it can allow more rapid evolution
of nmh because it wouldn't be as bound by compatibility and
1) It can be a fork of the current nmh code base.
2) It can be a proving ground for new ideas and implementations.
If some are deemed suitable for inclusion into nmh, that's
fine. If not, that's fine, too. It should be useful and
usable on its own.
3) It can sacrifice compatibility, whereas nmh must try to
avoid user-visible, incompatible changes.
4) It can be implemented in languages other than C.
5) It need not be portable to odd (say, non-POSIX) platforms.
I don't care what "it" is called.
Having the goals clearly stated would allow me to figure out if it's
worthwhile for me to try to add value to this community and project.
If someone has personal opinions on this subject, I welcome them too.
Nmh is clearly your project and not mine, besides being Free Software.
I don't want to sail in your waters if you don't like.
I don't think it's necessary or useful to think in such terms
as "your" and "mine". And I, for one, welcome your (and anyone
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