Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <46efd4f2168b58c0da45c08b120a1b3deef9e169.camel@perches.com>
Subject: Re: [Ksummit-discuss] crediting bug reports and fixes folded into
 original patch
From:   Joe Perches <joe@perches.com>
To:     Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc:     James Bottomley <James.Bottomley@hansenpartnership.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        "ksummit-discuss@lists.linuxfoundation.org" 
        <ksummit-discuss@lists.linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>
Date:   Thu, 03 Dec 2020 11:24:43 -0800
In-Reply-To: <20201203191731.bpzvwqfldhcjhzfy@chatter.i7.local>
References: <ea32eb02-5e44-0469-772b-34b5cb882543@suse.cz>
         <694039d6e386d999fd74d038cf2627f5b3b0ca71.camel@HansenPartnership.com>
         <3c11134905f06185dda4e9125f2fb7fd30fff979.camel@perches.com>
         <20201203191731.bpzvwqfldhcjhzfy@chatter.i7.local>
Content-Type: text/plain; charset="ISO-8859-1"
User-Agent: Evolution 3.38.1-1 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Thu, 2020-12-03 at 14:17 -0500, Konstantin Ryabitsev wrote:
> On Thu, Dec 03, 2020 at 08:55:54AM -0800, Joe Perches wrote:
> > Perhaps automate a mechanism to capture that information as
> > git notes for the patches when applied.
> 
> Git notes have a limited usefulness for this -- they are indeed part of 
> the repository, but they aren't replicated unless someone does a 
> --mirror clone (or specifically fetches refs/notes/*). If the goal is to 
> improve visibility for contributors, then putting this info into a git 
> note will hardly make more difference than providing a Link: that 
> someone has to follow to a list archival service.

Or it becomes standard to fetch the refs/notes/... at the pull time.

> I can offer the following proposal:
> 
> - kernel.org already monitors all mailing lists that are archived on 
> ??lore.kernel.org for the purposes of pull request tracking 
> ??(pr-tracker-bot).
> - in the near future, we will add a separate process that will 
> ??auto-explode all pull requests into individual patches and add them
> ??to a separate public-inbox archive (think of it as another 
> ??transparency log, since pull requests are transient and opaque).
> 
> We can additionally:
> 
> - identify all Link: and Message-Id: entries in commit messages, 
> ??retrieve the threads they refer to, and archive them as part of the 
> ??same (or adjacent) transparency log.
> 
> This offers an improvement over the status quo, because if 
> lore.kernel.org becomes unavailable, someone would have to have access 
> to all backend archive repositories it is currently tracking in order to 
> be able to reconstitute relevant conversations -- whereas with this 
> change, it should be sufficient to just have the copy of the 
> transparency log to have a fully self-contained high-relevancy archive 
> of both individual commits and conversations that happened around them.

I think that would be great.  Thanks.

I think all the requests for additional -by: -from: signature/bylines
becoe unnecessary if and when this proposal is implemented.