Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches

From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Shuah Khan <skhan@linuxfoundation.org>,
	ksummit@lists.linux.dev
Subject: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
Date: Fri, 23 Apr 2021 14:57:58 +0200	[thread overview]
Message-ID: <20210423145758.4c6c144d@coco.lan> (raw)
In-Reply-To: <20210423111606.GC8755@quack2.suse.cz>

Em Fri, 23 Apr 2021 13:16:06 +0200
Jan Kara <jack@suse.cz> escreveu:

> On Thu 22-04-21 13:08:09, Martin K. Petersen wrote:
> > 
> > Jan,
> >   
> > > Is it that hard to improve quilt?  
> > 
> > Now that we have tighter integration between the various components of
> > our infrastructure, I wonder if we should reconsider the patch
> > submission process?
> > 
> > Instead of putting the burden on the submitter to pick the right 20
> > mailing lists to CC: and accommodate 100 developers and maintainers with
> > individual delivery preferences, why not let the k.org infrastructure
> > automate that aspect?
> > 
> > Have a patch ingress email address that runs get_maintainer.pl to figure
> > out who to reach out to. And then everybody with a kernel.org account
> > can twiddle their preferences wrt. whether to receive the whole series,
> > only patches that touch files they are responsible for, opt not to
> > receive individual mails but only the relevant mailing list copy,
> > whether to receive stable backport notifications, etc.
> > 
> > That would substantially lower the barrier of entry for patch
> > submitters. More work for Konstantin, obviously. And potentially some
> > transitional grievances for most of the rest of us based on our
> > individual workflows and preferences.
> > 
> > Just an idea, I know it's a bit controversial. However, there seems to
> > be no shortage of problems originating in the patch mail preparation and
> > sending department. Seems like a bigger barrier for some than developing
> > the actual patch.
> > 
> > We could even consider supporting receiving and disseminating git
> > bundles on the ingress. That would help overcome the many problems with
> > corporate email servers vs. git send-email. A ton of problems are
> > introduced as developers copy and paste things from their corporate
> > email to GMail, etc. Seems like our backend tooling could help alleviate
> > some of those pains without completely wrecking the mail-based flow we
> > maintainers are comfortable with...  
> 
> I agree this would be a nicer solution and I think something like this is
> eventual Konstantin's goal. So hopefully we'll get there once :)

The idea is nice, but, for this to work, the reply-to address should point
to some bot at kernel.org infra, as all replies to a given patch (or cover)
should be replied to everyone that it was c/c on the original e-mail, plus
the patch submitter.

Thanks,
Mauro