Re: RFE: use patchwork to submit a patch

From: Dmitry Vyukov <dvyukov@google.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	patchwork@lists.ozlabs.org, workflows@vger.kernel.org
Subject: Re: RFE: use patchwork to submit a patch
Date: Thu, 24 Oct 2019 16:12:12 +0200	[thread overview]
Message-ID: <CACT4Y+aCq+AVeCtJM8BbppQQ4ePu2OXmAL1Unda_=ER9sd4yeg@mail.gmail.com> (raw)
In-Reply-To: <20191024095839.44429eeb@gandalf.local.home>

On Thu, Oct 24, 2019 at 3:58 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Thu, 24 Oct 2019 15:33:04 +0200
> Dmitry Vyukov <dvyukov@google.com> wrote:
>
> > On Thu, Oct 24, 2019 at 3:15 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> > >
> > > On Mon, 21 Oct 2019 18:39:18 +0300
> > > Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> >
> > Purely theoretically let's consider that the changes do not improve
> > _your_ efficiency, but they significantly improve overall project
> > efficiency by positively affecting people who did not develop a
> > workflow over the past decades (maybe there were not around 2 decades
> > ago) and positively affecting various tooling that _you_ may be
> > directly interested in, but otherwise they are important for the
> > project overall. So for you it's no change in efficiency except that
> > you now need to do things differently. What do you think about such
> > changes? Are you ready to force yourself? :)
> > I think it's quite cornerstone question here. All (?) major figures in
> > the kernel (who are ~~98% of decision making, but ~~2% of kernel
> > developers overall) have developed workflows over the past decades
> > that work reasonably well for them. If they veto all proposed changes
> > based on the criteria you described, every new contributor will need
> > decades to develop own workflows to become an efficient contributor
> > and lots of tooling will be painfully hard to do.
> >
>
> The above sound like a one size fits all approach, which I would caste
> a veto to. I would like a solution that works for multiple workflows.
> One where mine and others still work too.
>
> Please, lets work on a infrastructure that is robust and flexible, that
> is split into back and front ends. That way, we have a single "back
> end" and multiple front ends that suite everyone's needs.
>
> -- Steve

I agree that the system must not lock in into a single UI.
However, (1) somebody will still need to glue all old frontends with
the new backend. (2) some workflows may still break regardless of a
perfect backend/frontend split. Consider, previously one could say in
arbitrary plain English that a bug X is fixed by commit Y, but if we
want to build anything on top of that can't be plain English anymore
and will require changes in workflows.

FWIW, Gerrit satisfies most of the criteria. It provides a nicely
formatted database that you can easily git fetch and take with you
offline. In this sense it is a robust and flexible backend. However,
one won't get all of hundreds of existing scripts and systems work on
top of it out-of-the-box.