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 much.) 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 upstreams.) -- 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