[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Reply semantics, yet again (was Re: Zoom- best practice?)

On 2020-06-10 at 09:27, Nicolas George wrote:

> The Wanderer (12020-06-09):

What's with the stray 1, here?

>> I subscribe to probably dozens of mailing lists, and I don't know
>> of any way to configure things to add that header with a proper
>> value automatically on a per-mailing-list basis. Otherwise, I'd
>> probably have done this years ago, unless other considerations
>> (e.g., UI for when I want to do this vs. when I really do want to
>> reply to the sender or to all recipients) took precedence.
> With Mutt, I use this:
> send-hook ~Cdebian-user@lists.debian.org my_hdr "Reply-To: debian-user@lists.debian.org"
> There is certainly an extension to Mozilla to do the same thing with
> a few dozen clics.

I haven't found one to date, but I'll look again.

>> For myself, I use the "Reply to List" button in (a now-old version
>> of) Thunderbird, and avoid the issue of Reply-To settings entirely
>> unless I actually do want to reply to something other than just the
>> list.
> That means you need to remember and take notice, each time you reply
> to a mail, whether you are replying to a list or not.

Not so much so; when not replying to a message received through a
mailing list, the button is grayed out and unavailable, because there is
no address for it to use.

So still "notice", to some degree, but not "remember", because the
software handles that for me.

> I personally reject any solution with that requirement, since there
> are solutions without.

Don't get me wrong; my original position on this, which I'd still prefer
a solution that makes possible, is that the basic Reply function should
do "smart" detection of the default reply target in all cases. I have
rants written up about what the logic for determining the default should
be, and I suspect that you'd agree with their results.

But I've seen persuasive argument that there's no way to make such
"smart" reply direction detection smart enough that you don't need to
override it in some cases, and that the number of different UI
elements which would be needed to for all the different possible
override types (reply respecting Reply-To, reply to sender, reply to
list, reply-all, reply to list and sender, reply respecting Reply-To
except also include list, ...) would very quickly proliferate to the
point of unwieldiness.

Imperfect though it is, he use of a separate "reply to list" button is
the least problematic option that's close to a general "usable across
all scenarios" solution that I've seen actually get implemented so far.

That said, as I said above, I'll look into the type of hook you
mentioned, and see whether it produces better results for my particular
case and sensibilities.

>> While I wouldn't necessarily take the argument as far as you appear
>> to, I am inclined to agree in principle.
>> That said, while this is an important aspect of the situation,
>> it's technically a tangent from the question of whether people
>> other than the developers can build the program and have the result
>> be usable. If we assume that the developers don't routinely update
>> or replace these prebuilt objects, and don't hack these objects
>> themselves as part of working on the project, then the tree we have
>> is the tree the developers build from - and if we can build a
>> working program from it, then that narrower question is answered
>> "yes".
> These thoughts caused me to consider an even scarier hypothesis:
> It's entirely possible that the authors of Jitsi themselves would not
> be able to build it from sources.

FWIW, since I wrote that I've looked at things a bit deeper. (Though not

They do, apparently, update the JARs (lib/installer-exclude/) on a
somewhat regular basis; there is a commit under that directory every few
months or so, and most of them involve a commit message which looks
related to updating from upstream.

The SOs (and DLLs, and .dylib / .jnilib files), on the other hand... the
most recent log entry for the lib/native/ directory is from 2017, and
the ones before that quickly go to 2016 and 2015 and on earlier. These
appear to be mostly put in place and ignored, except when something
breaks. (On the Linux side, only one of the .so files - libunix-java.so
- appears to exist in current Debian testing / stable; that does not
speak well for the possibility of being able to identify the appropriate

   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: