Hi Branden, > Date: 2026-07-31 18:57:47-0500 > From: "G. Branden Robinson" <[email protected]> > > Hi Joseph, > > At 2026-07-31T23:28:19+0000, Joseph Myers wrote: > > And I consider it an abuse of position to change man-pages to declare > > to users in general of C libraries on GNU/Linux that your standards > > proposal, at a very early stage (not even an N-document), is the One > > True Way of using the functions. > > I agree that there is a _potential_ moral hazard here. > > > It would be more neutral to say in the man pages that "as of July > > 2026, one member of WG14 has proposed moving these functions to > > <memory.h> [reference]; this proposal has not yet been considered by > > WG14". (I doubt the utility to users of describing proposed changes > > in man-pages at such an early stage, especially since the information > > would be long obsolete by the time those revisions of the pages make > > it into distributions, but it would at least more accurately reflect > > reality, and be vaguely neutral as long as you do it for *everyone's* > > open proposals, *including those you personally disagree with*, rather > > than privileging your own.) > > I endorse this perspective. Another thing Alex could do is gate such > readily-obsolescent stuff behind a *roff register so that it doesn't > format (or, if one uses soelim(1), even populate the document sources), > for _official releases_, but is still there for people pulling on Alex's > Git repository. > > My interpretation of Alex's tactics is that he feels energetic about his > proposal, is willing to think it through carefully and advocate for > it--these are good things--and that he wants to get it in front of > domain experts and anneal it by fire before formally putting it before > WG14--_also_ a good thing! In the meantime, he is the steward of a > platform that _is_ topically implicated. > > Such a position _can_ be abused, but it also seems not quite fair to me > to expect him to stifle his advocacy in a _relevant_ forum. > > Conventionally, what Alex faces is a potential conflict of interest. > There are a variety of ways to cope with those. Foremost is disclosure > to others of the potential conflict. That's such an important factor > that I'd say it's 90% of the battle. Most of the time when people > resist disclosing potential CofIs it's because they're self-dealing, > they know it, and realize that disclosure would be self-incriminating.
Indeed. While I haven't explicitly mentioned CofI, I haven't hidden it either, and have mentioned all the relevant information. If I haven't merged this single-handedly, it's precisely because I think there could be some, and want to get feedback. Cheers, Alex > > There is another tier to the issue, and its recourse is recusal. We > most often see this in the context of arbitration or in the judiciary. > > However, Alex is not situated as a judge or gatekeeper here. To WG14, > and to C library maintainers, he is an advocate. Has Alex rejected any > proposed patches to the Linux man-pages along similar lines as his own > advocacy? That would be gatekeeping. > > Alex might consider deputizing a fellow maintainer to handle updates to > portions of man pages where he has, or expects to have, business before > WG14. > > Regards, > Branden -- <https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
