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

["Theodore Y. Ts'o" <tytso@mit.edu>]

On Wed, Aug 28, 2019 at 08:38:33AM -0400, Joel Fernandes via Ksummit-discuss wrote:
> The idea is to make it trivial. All of the steps above are automatic
> and scripted, that's the whole point of what I was saying - to make it
> automatic. If it is not automated, then it is unlikely to be adopted
> widely or unlikely to stick. The final user will experience it as
> trivial.

I'm going to gently suggest that we've reached the point where instead
of people trying to argue for their suggested solution is to actually
*implement* a prototype.  It'll be a lot easier for people to judge a
particular solution if it exists, than to debate about vaporware.

Code implementing automation can always be adjusted, and questions
over whether the Link: trailer should be using lkml.kernel.org or
lore.kernel.org is really paint shedding.

Also remember that, different people can start using different
automations, and even different schemes, in parallel, and we can
actually try them out and see which is:

* most convenient for the patch submmiter
* most convenient for the maintainer
* most convenient for people who are doing code archeology

etc.  Then we can decide on what we want to use.  Trying to pick
something before people who actually have to use it day to day have
had a chance to try it in real life is how CIO's end up picking Lotus
Notes.

Even people who are arguing for using Change-Id will have better luck
if there is a commonly available solution in active use which makes
Change-Id's actually *useful* as a search token, as opposed to today,
where it is viewed (in practical terms, given today's usage, mostly
correctly) as a proxy for Gerrit instances hidden behind corporate
firewalls.

						- Ted