Hi Alex, At 2023-11-22T18:26:38+0100, Alejandro Colomar wrote: > On Wed, Nov 22, 2023 at 10:25:57AM -0600, G. Branden Robinson wrote: > > I think you should alter this advice to employ the active voice, not > > the passive. When an authority is dispensing advice or direction, > > people need to know who that authority is. In this case, it would > > appear to be the Linux man-pages project maintainers. If there is > > an external authority whose advice you are transmitting, then that > > authority should likewise be cited by name. > > Both. I was advising, as you guessed, but gpg also does. How about > the following? > > > <diff --git a/CONTRIBUTING b/CONTRIBUTING > index 7b85e7375..bde085a63 100644 > --- a/CONTRIBUTING > +++ b/CONTRIBUTING > @@ -57,13 +57,14 @@ Description > help > > Sign your emails with PGP > - It is strongly encouraged that you sign all of your emails sent > - to the mailing list, (especially) including the ones containing > + We strongly encourage that you sign all of your emails sent to > + the mailing list, (especially) including the ones containing > patches, with your PGP key. This helps establish trust between > you and other contributors of this project, and prevent others > impersonating you. If you don't have a key, it's not mandatory > to sign your email, but you're encouraged to create and start > - using a PGP key. > + using a PGP key. See also: > + <https://www.gnupg.org/faq/gnupg-faq.html#use_pgpmime> LGTM! > > I find it awkward to "strongly recommend" a best practice that isn't > > easily facilitated by _any_ readily available tool without further > > hacking. > > I find it awkward that mutt(1) disables crypto operations in [...] > I also find it awkward that when patatt(1) (and b4(1) wrapping it) [...] > I also find it awkward that MUAs (or actually anybody) don't seem to Anaphora FTW! But don't stumble and fall into a chiasmus. ;-P [...] > I won't concede this. I strongly encourage everybody to sign mail and > patches, and to encrypt whenever possible. And also strongly > encourage everybody to press the powers that be (i.e., maintainers of > MUAs) to make it easier. That present-day technology sucks doesn't > lower the strength of my encouragement. > > > I "manually" sign my messages to this list (that is, via > > keyboard-driven > > I find it really awkward that you need to do it manually. I suggest > you to try and patch mutt(1), if you can. I'm sure I _can_, with sufficient effort. A bear of very little brain should be able to manage. But as a rule, I maintain local forks only of projects that I frequently work on. Experience has taught me that when I don't, and my upstream upgrades, it's too often a hard slog to re-fork. I forget things and have to relearn them, and/or upstream has refactored so much that I no longer recognize what I _need_ to patch. MUA development is not an area I have yet found seductive. I petition you to soften the language because I don't think you want to give the impression that you'd prefer a patch go unsubmitted rather than show up un-GPG-signed. (Am I mistaken?) In fact, you might explicitly state how your handling process differs for unsigned vs. signed patches. If there _is_ no difference--if there is no queue penalty, or additional follow-up to authenticate the sender that you undertake--then I suggest that what you're doing is turning this aspect of the Linux man-pages contribution process into a platform for editorializing about your preferences. Now, far be it from me to rebuke anyone for expressing opinions: practically every email I write is loaded with 'em. And in fact I largely share your preference here, and have long (for 20+ years) wondered why MUAs don't read your keyring and offer opportunistic encryption of mails sent exclusively (To+Cc) to accounts in the keyring. _But_ when you're employing the resources of a project X to pursue an agenda with respect to projects W, Y, and Z (MUAs), I think it wise to be forthright. You might therefore articulate a concrete policy wherein you impose a tax on unsigned patch submissions--or disclose the added costs that you accrue when dealing with them. If you're not willing to do so, for whatever reasons you can think of that make either one a bad idea, then I repeat my advice to soften the language in the CONTRIBUTING.md file. Or to redirect it: instead of inviting the patch submitter to infer that the burden is on them to use tools that haven't yet been adequately developed, you can express your grievance with MUAs in a paragraph or two as an aside. There's nothing inherently wrong with doing this. MUAs are obviously relevant to a cooperative development process that is reliant on email. You don't want to try the patience of your reader, but you do want to alert them to a problem that has gone unsolved for a long time. And I think that--as long as you don't make your editorial aside an Invariant Section under the GNU FDL ;-)--people won't mind its presence. > If you're unlucky, you'll be locked in some neomutt(1) features, in > which case you're out of luck, as my suggested trick doesn't seem to > work (but if it works, please let me know). My continued use of neomutt is pure inertia. I gather that in the wake of some contretemps in Debian regarding the naming of the mutt and neomutt packages, mutt's upstream awakened and undertook active development again. This is a good thing. > I just found an erratum in K&R C v2 §5.5: In page 97, in the picture, > 'amessage' and 'pmessage' are switched (IMO); pmessage should be the > one with the two boxes and an arrow, since it's the pointer one. Is > there a published errata for K&R C v2 so I can check this and report? Yes... https://s3-us-west-2.amazonaws.com/belllabs-microsite-dritchie/cbook/2ediffs.html ..via... https://www.cs.princeton.edu/~bwk/cbook.html ...but the errata claim not to have been updated since October 2006. Nevertheless your proposed erratum does not appear in that document, so you might have a legit catch here. Time to email BWK and report it? ;-) > And even the wording in the book shows that they didn't know that > these functions are ill-designed (they are still useful in niche use > cases, but I doubt they were designed with those cases in mind). > Here's the quote. I've seen the _original_ set of C string-handling functions attributed to Nils-Peter Nelson (who was also in charge of DWB troff for a while). Here they are, in the earliest form known to me: https://minnie.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/include/string.h (note the SCCS ident[1]) ...but Nils-Peter probably cannot be blamed for directions this family of functions took subsequently. > < Write versions of the library functions strncpy, strncat, and > < strncmp, which operate on at most the first n characters of their > < argument strings > > To which of the args does 'n' apply? One (which?) or both? > strncat(3) is not limited to 'n' characters in dst, so this 'n' > applies to some random argument depending on the function: 1st for > strncpy(3) (but kind of both), 2nd for strncat(3), both for > strncmp(3). If you want to have some fun reviewing code, let me point you here. https://minnie.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/src/lib/libc/port/gen Regards, Branden [1] ...likely a misnomer, but calling it the "SCCS 'what'" doesn't get the idea across clearly. Incidentally the story behind SCCS vs. RCS is an intriguingly ugly one. (AT&T being stereotypically dumb about software licensing is not part of it.) We enlightened Git users have nothing whatsoever to learn from it, do we?
Attachment:
signature.asc
Description: PGP signature
