Date:   Wed, 1 Mar 2023 22:19:22 -0500
From:   Richard Acayan <mailingradian@gmail.com>
To:     Hector Martin <marcan@marcan.st>, linux-kernel@vger.kernel.org
Cc:     Asahi Lina <lina@asahilina.net>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg KH <gregkh@linuxfoundation.org>,
        Michael Dolan <mdolan@linuxfoundation.org>
Subject: Re: Linux kernel DCO
Message-ID: <ZAAVuo81E3XA6/LS@radian>
References: <Y820a/niMYtHfe8k@radian>
 <58a5ad01-dbfc-04a7-2234-c57bb627ee84@marcan.st>
 <Y84K1N3fzz/J4Pxa@radian>
 <6d96fb3c-9027-c612-fca4-e22c7c19186f@marcan.st>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6d96fb3c-9027-c612-fca4-e22c7c19186f@marcan.st>
Precedence: bulk

Hi,

On Mon, Jan 23, 2023 at 01:50:33PM +0900, Hector Martin wrote:
> On 23/01/2023 13.19, Richard Acayan wrote:
>> On Mon, Jan 23, 2023 at 10:42:21AM +0900, Hector Martin wrote:
>>> Hi,
>>>
>>> On 23/01/2023 07.13, Richard Acayan wrote:
>>>> 	Considering marcan knows you enough to let you use his stream
>>>> 	keys, his own sign-offs might properly certify the origin of
>>>> 	these patches. No matter how this was done, it should be
>>>> 	documented in case someone in a similar situation wants to
>>>> 	contribute pseudonymously and possibly anonymously.
>>>
>>> This is standard procedure for patches submitted to subsystem trees
>>> (i.e. us subsystem maintainers have to sign off before committing to our
>>> tree and sending the pull upstream). That means patch authorship
>>> concerns are something for us maintainers to worry about, not any
>>> downstream kernel users.
>> I hope Will Deacon knows what they're signing up/off for in [6], then.
>> 
>> Is this documented? How would anyone know?
>
> And therein lies the problem with the "rule". It is unenforceable, and
> completely unenforced. Nobody is checking IDs, nobody expects to check
> IDs, and nobody expects people to check IDs.
>
> When Arnd signed my PGP key and blessed me as a sub-maintainer, he
> *explicitly* made a point to me that what the kernel community cares
> about is continuity of authorship and trust, not whatever combination of
> characters happens to be attached to it, and declined to check my ID.
>
> See also the DRM maintainers' opinion:
>
> https://lore.kernel.org/dri-devel/CAPM=9twCiqyakgPLz0v=7-abUhzLb8ZZH7-U65PV8qtQOP7Xww@mail.gmail.com/
>
> Now Greg might disagree with this, but this is already the stance of a
> good fraction of the kernel community, as you can see. Just because Greg
> sent a change 17 years ago doesn't mean everyone today thinks it's a
> good idea or even meaningful in any practical way.
>
>>> Without commenting on Lina's situation in particular, you should know
>>> that there are already quite a few pseudonymous contributions to the
>>> Linux kernel (if you go digging through git logs, it won't take long to
>>> find some interesting names - try grepping for 'George Spelvin'). So
>>> again, if this were of significant concern downstream, that would've
>>> been brought up long ago.
>> I was not aware of this. Nor was "Newbyte", with 3 patches applied to
>> linux-next, or "Hakurei Reimu", someone who does work on old Samsung

In retrospect, I did not ask these people for permission before
mentioning them. Maybe they knew and chose to do away with aliases
anyway.

>> phones, with 22. The chat log [4] shows how this was discovered at all,
>> initially starting with a tweet/toot [7][8].
>> 
>> Documentation/process/submitting-patches.rst:
>> 
>> 	then you just add a line saying::
>> 	
>> 		Signed-off-by: Random J Developer <random@developer.example.org>
>> 	
>> 	using your real name (sorry, no pseudonyms or anonymous contributions.)
>> 
>> The kernel documentation tells you to use your real name when submitting
>> patches. That's what most people, distro maintainers and contributors
>> alike, expect as a rule. To reiterate my last quoted sentence, maybe
>> this should be changed so the rules aren't confusing?
>
> Distro maintainers don't and absolutely should not care because their
> job is not to audit kernel contributions for authorship. The vast
> majority of open source projects do not have any such rules, including
> Mesa (where Lina was just made an official maintainer and given commit
> access a few days ago, for whatever that's worth). No distro has a rule
> that all contributions to all packaged software must use real names,
> because such a rule would disqualify the vast majority of the open
> source ecosystem. It is only the kernel and a few (mostly
> corporate-managed, draconian-CLA-required style) projects that have this
> kind of rule. And so it is for those projects to deal with, not any
> consumers.
>
> I agree that this should be changed (for many reasons, I could write
> about this at length), and as I'm sure you can imagine, such change
> would probably have to be a coordinated push with buy-in from several
> kernel stakeholders. So I would appreciate it if you don't turn this
> into a public discussion at this time, and let us figure out how to deal
> with it when the time comes.

Sorry to bother you, but what happened?

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d4563201f33a022fc0353033d9dfeb1606a88330

Two Acked-by's are a bit underwhelming for a coordinated push with
buy-in from several kernel stakeholders. According to the commit
message, there wasn't even much of a discussion since the first email in
this thread.

Did Linus have an afterthought this weekend, independant of this
discussion? Did that "fire" Mastodon toot have anything to do with this?

With my first contribution, I had the perception that anyone with a
computer and good email provider (there are some practical exceptions to
this) could contribute to the mainline Linux kernel. After managing
someone's 5-year-old patch, I percieved that you can even do it by
accident.

Of course, it's easy to call this naive and ignorant. I accepted this
explanation and respected this request to not turn this into a public
discussion until the time comes. Now, I wonder if this patch was written
and applied later than it should have been because we misunderstood the
kernel contribution process as an aristocracy for this specific case.

>
> - Hector