Alright, here are some things I've been thinking about in no particular
order:
- I think we have enough new stuff that a new release based on the tip
of master is worthwhile. Let's call it 1.5, since it doesn't feel
fresh enough to me to make it a 2.0. I'd rather invest my energy in
doing that than release a 1.4.1 with just the fixes for dist. I was
thinking about doing this in a few weeks.
- I propose a new naming policy for tags & release branches:
- The release branch is called "1.5-release"
- Tags on the branch corresponding to the release are in the form "1.5"
- A tag is created on the master branch at the branch point in the
form "1.5-dev" (this is so "git describe" is useful on master).
Objections? The previous naming scheme(s) aren't uniform and also were
based on CVS limitations. This will also make stuff downloaded from
gitweb have more sensible names.
- In terms of the new features, here's what I've discovered:
- The format stuff works for selecting From: headers in replcomps, but
it gets a bit cumbersome if you want to have multiple conditions
match the same address. Also, you can't have comments inside certain
parts of if statements (%< ... %>). But once you puzzle out some
underdocumented parts of the format syntax, you can make it work.
- The filtering stuff with mhl also works, but it has a few warts.
I set my formatproc to "par" and I discovered that with the default
settings "par" will exit with an error if it gets a line that
it cannot split (think a long URL). You can turn that off, but I
then discovered that I didn't have mhl error if the filter program
exits with a non-zero exit code. Should it? I think so; looks
like all of the other programs do that. Other than that (and bad
behavior with quoted-printable parts) it works fine.
- I've heard about people that have written MIME wrappers to repl; do
people want to post them here? It might be useful to see if these
wrappers could be adapted as mhl filters to be used in repl.
- I discovered that with making REALLYDUMB the default, I've run into
a number of cases where my draft doesn't have a From: header (this
happens when using dist or forw), and the constructed one is wrong
(either it's "kenh" which our SMTP server now rejects, or at home
it's "kenh@pendragon.internal", which is also rejected. I've
realized that we should deal better with this. I propose we have
a new .mh_profile entry that is used as the default From: when one
isn't supplied in a draft. Objections?
- Jerry Peek, this is for you, assuming you're still around. The MH/nmh
book is a great resource, but it hasn't been updated in a while. Would
you be interested in updating some stuff for some of the newer nmh
features? I'm thinking specifically of the new format/mhl filter,
SMTP server/port selection, authentication with Cyrus-SASL, those
sorts of things. I could help you with that, it's just that I'm not
really a writer.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers