My patch was not accepted in 2009

[Bertram Scharpf]

Hello,

almost nine years ago I suggested an enhancement to Mutt and
then wrote a patch. It was about encryption: If I write a
message, then encrypt it for the recipient and keep just the
encrypted copy, I will later not be able to read what I
wrote myself. I suggested an option that added myself to the
recipients list when calling GnuPG or OpenSSL.

However, the only person that seemed a little bit interested
was Rocco Rutte who passed away some weeks later. I was just
instructed that it is not a mail clients problem and that I
should configure GnuPG to do what I want. In plain language:
Go away.
<https://marc.info/?l=mutt-users&m=124829743406575&w=2>

So I decided not to bother the wise developer community of
Mutt any more.

Last week I detected that there is an option doing partially
what I suggested since 2017, yet eight years after my
proposal. The patch still isn't as good as mine but knowing
that the noble people that sent me away nine years ago
weren't right makes me quite satified.

So, please excuse me for writing this story to the list and
taking again so much of your precious time. Be sure that I
will not ask you anything any more.

Bertram

[Claus Assmann]

Post by Bertram Scharpf
It was about encryption: If I write a
message, then encrypt it for the recipient and keep just the
encrypted copy, I will later not be able to read what I
wrote myself. I suggested an option that added myself to the
recipients list when calling GnuPG or OpenSSL.

What's wrong with doing that?

gpg:
--encrypt-to name
Same as --recipient but this one is intended for use in the
options file and may be used with your own user-id as an
"encrypt-to-self". These keys are only used when there are other
recipients given either by use of --recipient or by the asked
user id. No trust checking is performed for these user ids and
even disabled keys can be used.
"Don't duplicate functionality"


Maybe if you explain why you need this option in mutt it would help...

[Vincent Lefevre]

Post by Claus Assmann

Post by Bertram Scharpf
It was about encryption: If I write a
message, then encrypt it for the recipient and keep just the
encrypted copy, I will later not be able to read what I
wrote myself. I suggested an option that added myself to the
recipients list when calling GnuPG or OpenSSL.

What's wrong with doing that?
--encrypt-to name
Same as --recipient but this one is intended for use in the
options file and may be used with your own user-id as an
"encrypt-to-self". These keys are only used when there are other
recipients given either by use of --recipient or by the asked
user id. No trust checking is performed for these user ids and
even disabled keys can be used.

Have you read what Bertram Scharpf wrote in his 2009 message?

Post by Claus Assmann
"Don't duplicate functionality"

As Bertram Scharpf explained, this is not.

Post by Claus Assmann
Maybe if you explain why you need this option in mutt it would help...

He did. But I assume that the new option does what he wants to do.

[Heinz Diehl]

Post by Bertram Scharpf
Last week I detected that there is an option doing partially
what I suggested since 2017, yet eight years after my
proposal. The patch still isn't as good as mine but knowing
that the noble people that sent me away nine years ago
weren't right makes me quite satified.

How about stopping complaining and submitting your code?
"Here are friendly creatures, not at all evil" :-)

[Derek Martin]

Post by Heinz Diehl

Post by Bertram Scharpf
Last week I detected that there is an option doing partially
what I suggested since 2017, yet eight years after my
proposal. The patch still isn't as good as mine but knowing
that the noble people that sent me away nine years ago
weren't right makes me quite satified.

How about stopping complaining and submitting your code?
"Here are friendly creatures, not at all evil" :-)

I don't think he's still listening... I would have loved a reference
to the original message. When I searched the archives on his name it
only turned up the current thread. My reaction was the same as
Claus': use gpg to add yourself to the recipient list. I'll concede
that might be different than adding the feature to mutt, in ways I
can't think of, but while I was a regular encryption user I used that
solution myself (technically still do, though it's much less relevant)
and can't see how it isn't adequate.

Every feature, every configuration variable, no matter how simple, has
a cost--not just in terms of the work to add the code, but also in
terms of making sure that future changes don't break existing
features. The more such things your software has, the harder it is to
make sure there are no bad interactions between future changes and
existing features. Thus when there is an alternative that does not
involve a Mutt code change, previous maintainers would tend to prefer
that, over taking a patch. I do not think it is a correct statement that
"the noble people that sent me away nine years ago weren't right..."
Rather I think it is just that each time the maintenance of Mutt has
changed hands, the new maintainer has been a bit less risk averse than
the previous one, in the name of progress.

In this I do not think there is a write or wrong, good or bad... There
is only include or do not include. Both choices have merits (assuming
the code is good), and both choices have costs, and the decision will
affect different users differently. I certainly understand that it
can be frustrating to make an improvement that you feel is necessary
to a piece of software you are invested in. But ultimately, it's up
to maintainer (perhaps with advice from the larger development
commuity) to decide what costs will be accepted; it is primarily the
maintainer who has to pay them. No one requesting a feature has a
right to demand the maintainer's time, and when you are indignant
about a patch you wrote not being included, that is what you are
doing--both now, and in perpetuity.