Hoi nmh community,
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).
The main topic of our disagreement is compatibility. I like to point
this out here, quoting replies to my proposal:
Subject: Re: [Nmh-workers] [patch] snapshot of my MIME handling improvments
[2010-11-12 17:55] Jon Steinhart <jon(_at_)fourwinds(_dot_)com>
I have difficulty seeing this as enough of a savings to be worth breaking
backward compatibility. If you really have to do this then you should
provide an upgrade script so that users don't get their stuff broken when
they upgrade.
(On the former sentence, see below. On the latter sentence, I agree.)
Subject: Re: [Nmh-workers] MIME questions, and followup to my earlier email
[2010-11-12 19:50] Jon Steinhart <jon(_at_)fourwinds(_dot_)com>
On my earlier email, I guess that I'm unhappy that meillo is making changes
that break things, even if those are minor things. Comments on my proposed
MIME-reading changes indicated that they should be optional for
compatibility
reasons. I took that approach when I implemented the MIME-sending changes.
I think that we should only break existing code for clear and compelling
technical reasons.
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.
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?
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
nmh.
Sorry, seems like my comments offended you. nmh is a community project. To me
that means that anybody can propose things but those things are subject to
review
by the larger community. The result usually turns out to be better. This
doesn't
mean that your efforts aren't appreciated. It helps to have a thick skin; it's
easy to get offended when people you've never met make comments.
Maybe I don't understand your proposed changes. Apologies if I get this wrong;
I didn't save a copy of your original email and the archives are currently down.
There are currently -attach options on send and whatnow to support the
non-standard
attachment header. I don't even think about this because my .mh_profile
includes:
send: -alias aliases -attach X-MH-Attachment
whatnow: -attach X-MH-Attachment
My understanding is that your change would be to remove the -attach options and
to
have the .mh_profile include something like this instead:
attach: X-MH_Attachment
Here are my unfiltered thoughts on this; maybe seeing them you can craft a more
compelling rationale for your proposed change:
1. It doesn't fix anything because the current mechanism isn't broken.
2. It doesn't simplify anything from a user perspective.
3. It just looks like a "semantic sugar" sort of change.
4. It breaks things for existing users.
5. Does he know that options can go into the .mh_profile?
6. I don't see any pros to outweigh the con of breaking things.
I would suggest that if there is a compelling reason for your change that you
could
do it without removing the old code. That way your new mechanism would work
without
breaking anything.
I know people who have crafted their own custom environments around the current
mechanism and an upgrade script is unlikely to catch them. nmh has a small but
dedicated user community and breaking things upsets them.
Finally, I think that the goal is to keep improving nmh which to me means
cleaning up
the codebase, fixing bugs, and adding new features. Your proposed change
doesn't appear
to do any of these unless I'm missing something.
Jon
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers