Linux Manual Pages development
 help / color / mirror / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: Alejandro Colomar <alx@kernel.org>
Cc: Luca Boccassi <luca.boccassi@gmail.com>,
	Askar Safin <safinaskar@gmail.com>,
	brauner@kernel.org, cyphar@cyphar.com,
	linux-fsdevel@vger.kernel.org, linux-man@vger.kernel.org
Subject: Re: [PATCH] man/man2/move_mount.2: document EINVAL on multiple instances
Date: Sun, 12 Oct 2025 13:57:03 -0500	[thread overview]
Message-ID: <20251012185703.oksyg4loz5fcassb@illithid> (raw)
In-Reply-To: <bc7w4t422bvpcylsagpsagl3orryepdbz4qimkuttd3ehtdsfu@thng5d5wn567>

[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]

Hi Alex,

At 2025-10-12T16:57:22+0200, Alejandro Colomar wrote:
> On Sun, Oct 12, 2025 at 03:25:37PM +0100, Luca Boccassi wrote:
> > On Sun, 12 Oct 2025 at 13:58, Askar Safin <safinaskar@gmail.com> wrote:
> > > So everything is working as intended, and no changes to manual
> > > pages are needed.
> > 
> > I don't think so. This was in a mount namespace, so it was not
> > shared, it was a new image, so not shared either, and '/' was not
> > involved at all. It's probably because you tried with a tmpfs
> > instead of an actual image.
> > 
> > But it really doesn't matter, I just wanted to save some time for
> > other people by documenting this, but it's really not worth having a
> > discussion over it, feel free to just disregard it. Thanks.
> 
> I appreciate you wanting to save time for other people by documenting
> it.  But we should also make sure we understand it fully before
> documenting it.  I'd like us to continue this discussion, to be able
> to understand it and thus document it.  I appreciate Aleksa and
> Askar's efforts in understanding this, and the discussion too, which
> helps me understand it too.  I can't blindly take patches without
> review, and this discussion helps a lot.

I have some unsolicited project management advice to offer.

I think you should say "won't" rather than "can't" in your final
sentence.  You are defending a point of policy--rightly so, in my view.
If someone wants to argue your preference on the subject, policy is the
correct ground upon which to engage.

The practice of distinguishing mechanism from policy is a valuable skill
in domains outside of software design where we most often speak of them.

It's even more important in the instant context to articulate matters of
policy when a contributor indulges a passive-aggressive outburst like
Luca's, above.  Confusion of mechanism with policy is the lever by which
that sort of emotionalism operates; obviously we _could_ just do
whatever a contributor wants without discussion and without
interrogating the wisdom of doing so.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2025-10-12 18:57 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-06 10:38 [PATCH] man/man2/move_mount.2: document EINVAL on multiple instances luca.boccassi
2025-10-06 11:19 ` Alejandro Colomar
2025-10-06 11:32   ` Luca Boccassi
2025-10-06 11:42     ` Alejandro Colomar
2025-10-06 11:46       ` Luca Boccassi
2025-10-06 11:57         ` Alejandro Colomar
2025-10-06 12:28           ` Luca Boccassi
2025-10-06 12:37             ` Alejandro Colomar
2025-10-06 13:11               ` Alejandro Colomar
2025-10-06 13:40             ` Aleksa Sarai
2025-10-06 13:44               ` Luca Boccassi
2025-10-07 18:37                 ` Aleksa Sarai
2025-10-07 18:38                   ` Luca Boccassi
2025-10-12  6:14                 ` Askar Safin
2025-10-12  9:40                   ` Luca Boccassi
2025-10-12 11:27                     ` Askar Safin
2025-10-12 12:58                     ` Askar Safin
2025-10-12 13:16                       ` Alejandro Colomar
2025-10-13  5:51                         ` Askar Safin
2025-10-12 14:25                       ` Luca Boccassi
2025-10-12 14:57                         ` Alejandro Colomar
2025-10-12 18:57                           ` G. Branden Robinson [this message]
2025-10-16 10:29                             ` Alejandro Colomar
2025-10-13  4:14                         ` Askar Safin
2025-10-22  7:36                 ` Christian Brauner
2025-10-06 11:29 ` [PATCH v2] " luca.boccassi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251012185703.oksyg4loz5fcassb@illithid \
    --to=g.branden.robinson@gmail.com \
    --cc=alx@kernel.org \
    --cc=brauner@kernel.org \
    --cc=cyphar@cyphar.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=luca.boccassi@gmail.com \
    --cc=safinaskar@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox