[nmh-workers] Novel Definition of Deprecation.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[nmh-workers] Novel Definition of Deprecation.

Ralph Corderoy
Hi Ken,

I thought a deprecating a part of nmh meant add the warning it was for
the axe in release N and axing it in release M where M>N.  But commit
43d9833b,
http://git.savannah.nongnu.org/cgit/nmh.git/commit/?id=43d9833bf1dcf38c7892a23951bf1d968028a15e
adds this to docs/pending-release-notes:

    - The generation and verification of Content-MD5 headers is no longer
      performed.  The -check and -nocheck switches to various nmh programs
      that would control this functionality still exist, but are non-functional
      and will be removed in the next release.

That's axing the feature without deprecation and trying to hoodwink the
user that it hasn't happened.  :-(

Either it should be deprecated, or axed in a release without
forewarning.  And if the latter then is that agreement we can do it for
other things too?  After all, many users don't read the release notes
and thus miss the deprecation warnings, or they upgrade several of our
releases in one bound due to their distro, etc., striding differently,
so a feature is effectively axed for them without warning anyway.

--
Cheers, Ralph.

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Novel Definition of Deprecation.

Ken Hornstein-2
>Either it should be deprecated, or axed in a release without
>forewarning.  And if the latter then is that agreement we can do it for
>other things too?  After all, many users don't read the release notes
>and thus miss the deprecation warnings, or they upgrade several of our
>releases in one bound due to their distro, etc., striding differently,
>so a feature is effectively axed for them without warning anyway.

Sigh.  Ok, you caught me on this one.

But ... in my defense, Content-MD5 is a giant steaming pile of poo
and I would argue strongly that it's good that it's gone.

First, this has been discussed being removed since 2013.  People
have argued that they have a use, and at first I was like, "Ok, sure,
keep it if people are using it".  But ... those arguments upon closer
look don't (IMHO) make a lot of sense.  Here are my arguments for getting
rid of it, from the last time I brought it up:

    https://lists.gnu.org/archive/html/nmh-workers/2018-07/msg00003.html

I mean ... can you muster a good argument to keep it?  I haven't
seen one yet that wasn't kind of vague, "Oh, I think it's good to be
able to check integrity", but since we're the only ones who generate
it or verify it, that doesn't seem enough justification to me.

Now, some people may say, "Oh, leaving it in doesn't harm anything".
Well, having been inside of nmh a lot I feel strongly that this is
wrong.  The INTERNALS of nmh are a mess.  The Content-MD5 support
was embedded at a bunch of weird layers (like in the base64 encoding
and decoding routines), and I understood WHY it was there, but it
makes maintenance a nightmare, because when someone looks at that code
they have to understand what is going on, and that takes time where
they COULD be doing something more useful.  Also, in the future where
I complete the Great Mime Rewrite there's no way I would implement
Content-MD5 (see above for the reasons why).

Okay, fine, I understand your complaint isn't really about the removal
of Content-MD5; your point is that I didn't really follow the normal
rules about deprecating the support and instead I just axed it.  I have
to plead guily there.  But at my sentencing hearing I would argue that
there were mitigating circumstances; namely that Content-MD5 support
is essentially useless and we are better off without it.  Does that
justify getting rid of it without going through the normal deprecation
schedule?  Well, I'll let others decide that.  My thinking was that for
the few users that still have -check in their .mh_profiles they will
hopefully see the change in the release notes and remove those flags.  I
didn't view it as harming anything because the only people who actually
generate or check Content-MD5 headers are nmh users who have -check in
their profiles and having those switches be nonfunctional won't really
change nmh behavior for them.  I have to believe that only a tiny number
of people are actually doing that now.  If you are suggesting that we
just go whole hog and remove the -check and -nocheck flags that now do
nothing ... well, I can live with that.

As for other features ... well, if they are in the same boat as
Content-MD5 then I am fine with treating them the same way (but really,
that'a a special case and I can't think of anything close to that).
Otherwise we should follow a normal depreciation schedule.

I guess in summary: "Yes, Your Honor, I killed Content-MD5, but he had
it coming and I'd do it again!".

--Ken

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Novel Definition of Deprecation.

Ralph Corderoy
Hi Ken,

> > Either it should be deprecated, or axed in a release without
> > forewarning.  And if the latter then is that agreement we can do it
> > for other things too?  After all, many users don't read the release
> > notes and thus miss the deprecation warnings, or they upgrade
> > several of our releases in one bound due to their distro, etc.,
> > striding differently, so a feature is effectively axed for them
> > without warning anyway.
...
> As for other features ... well, if they are in the same boat as
> Content-MD5 then I am fine with treating them the same way (but
> really, that'a a special case and I can't think of anything close to
> that).  Otherwise we should follow a normal depreciation schedule.

But what about our releases not matching many users' upgrade schedules
so our one-release deprecation notice is of no use to many?  That would
suggest more rapid change could be possible without the wait-a-release
delay.  The¬†alternative is to fudge it by releasing more often so we can
hoodwink them in another way that they were given fair notice.  :-)

--
Cheers, Ralph.

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Novel Definition of Deprecation.

Ken Hornstein-2
>But what about our releases not matching many users' upgrade schedules
>so our one-release deprecation notice is of no use to many?  That would
>suggest more rapid change could be possible without the wait-a-release
>delay.  The¬†alternative is to fudge it by releasing more often so we can
>hoodwink them in another way that they were given fair notice.  :-)

Sigh.  I think we're overthinking this ... there are no good answers.
I'm not so fond of releasing more often when there hasn't been
significant changes (we do have some reasonable bug fixes that have
occured since 1.7.1).  We're going to have users bitten by unexpected
changes, and that's just a fact of life.  I'm fine with the current
"keep for one release" schedule.  We have simply killed without
deprecating some other features along the way that were unused or didn't
make any sense anymore.

--Ken

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers