Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Jon Steinhart]

> 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 <address@hidden>
> > 
> > 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 <address@hidden>
> > 
> > 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