Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits

[Joel Fernandes <joelaf@google.com>]

On Thu, Aug 22, 2019 at 9:07 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Thu, Aug 22, 2019 at 5:17 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > > To begin with, let me make sure we're on the same page about what
> > > Change-Ids are.  As I understand it:
> > >
> > > * A change ID is much alike a UUID.  It is locally generated on a
> > > developer's computer and is (in theory) unique across the universe.
> >
> > Completely irrelevant.
> >
> > The point of an UUID is not just that it's unique, but THAT YOU CAN
> > LOOK SOMETHING UP USING IT!
> >
> > A "change ID" that I can't use to look anything up with is completely
> > pointless and should be removed from kernel history.
> >
> > But if you have something unique that is actually useful for looking
> > things up, then by all means. But it needs to be useful for
> > _everybody_.
>
> I presumably wasn't clear in my proposal.  My apologies and I will try
> to be clearer.  I am proposing this:
>
> 1. I post v1 of my patch series to public mailing lists, like LKML.
> Each patch in the series is tagged with a Change-Id which my own PC
> made up.  I never touch a gerrit server anywhere.
>
> 2. I post v2 of my patch series to a public mailing list.  I make sure
> that patches that are supposed to be newer versions of the same patch
> in v1 contain the same Change-Id that they had in v1.  This is
> something I already know how to do since sometimes I use gerrit and
> that's how you work with gerrit.  I still haven't touched a single
> gerrit server in this process.
>
> 3. The patch lands and still has the Change-Id.
>
> Someone looking at the git history in the kernel can find the old
> versions by searching public mailing lists for the Change-Id simply
> using the standard ways to search mailing lists for a string.  There
> is nothing excluding anyone here and it should be useful for everyone.
>
> Someone doing a search of the mailing lists that finds patch v1 can
> note the Change-Id and search the same mailing lists (and the kernel
> history) for that Change-Id.  They can find it because the same string
> was in v1 and v2.
>
>
> > > * When a developer keeps the same Change-Id across two patches they
> > > are making the assertion that the two patches are either the same or
> > > should be treated as two versions of the same logical change.
> >
> > .. and we have better ways to do that.
> >
> > For example, we are actively encouraging things like message ID's
> > (which are _also_ a form of locally generated UUID, they just are more
> > than the silly purely numerical one).
> >
> > That gives you the origin of something, but it also gives you the
> > development history and context.
>
> I do not believe that there is any way to start with the Message-Id of
> v2 of a patch and easily find v1 of the same patch.  Things like
> cregit and email2git may have heuristics here, but I'm fairly certain
> that they are not guaranteed to work.  I am happy to be corrected
> here.  I can also spend time finding examples of cregit and email2git
> failing if needed.

Could email2git be made more robust - if each revision of a patch
contained a Message-id of the previous revision(s), then it strings
them together? A list post already has a Message-Id to uniquely
identify it.

Also Message-Id is more flexible, it can be used to refer to other
patches or other discussions which may not necessarily refer to older
patch revisions.

I see your point, but IMO - I don't think it is practical to force all
Linux contributors to use a new Change-Id and expect that they will
stick to using it. It is better to use existing tools.

thanks,

 - Joel
[snip]