Re: thoughts on a Merge Request based development workflow

From: Daniel Axtens <dja@axtens.net>
To: Dave Airlie <airlied@gmail.com>, Steven Rostedt <rostedt@goodmis.org>
Cc: Neil Horman <nhorman@tuxdriver.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Drew DeVault <sir@cmpwn.com>,
	workflows@vger.kernel.org
Subject: Re: thoughts on a Merge Request based development workflow
Date: Tue, 01 Oct 2019 13:22:09 +1000	[thread overview]
Message-ID: <87eezx40bi.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <CAPM=9tzbwop5Wv9u5d2rDz_-eUmfckJdYff4WVnmAZKf-yBXXw@mail.gmail.com>

Dave Airlie <airlied@gmail.com> writes:

> On Sun, 29 Sep 2019 at 09:10, Steven Rostedt <rostedt@goodmis.org> wrote:
>>
>> On Wed, 25 Sep 2019 20:40:45 -0400
>> Neil Horman <nhorman@tuxdriver.com> wrote:
>>
>> > Eventually, barring any really significant objection, hes going to make
>> > the switch, and users will either have to get github accounts, or stop
>> > participating in netdev development.
>>
>> That will be a very sad day if that happened.
>>
>> Whatever service should have an email interface. For example, if I get
>> a message from bugzilla.kernel.org, I can reply back via email and it
>> is inserted into the tool (as I see my Out of office messages going
>> into it. I need to fix my scripts not to reply to bugzilla).
>>
>> I set up patchwork on my INBOX, as I'm having a hard time of separating
>> patches from the noise. And it works really well. I would love to be
>> able to push my patchwork list to a public place so that others can see
>> it too. As mentioned in the Maintainers Summit, it would be great to be
>> able to pull patchwork down to my laptop, get on the plane, process a
>> bunch of patches while flying, and then when I land, I could push the
>> updates to the public server.
>>
>> That's pretty much all I'm looking for.
>
> How many patches is your workflow btw? 20 a month? 50?
>
> I think the reason davem and my group have in using git(hub/lab) is
> our patch counts are way higher. You guys are inventing solutions for
> your problems that's great, but they don't scale.
>
> Patchwork as currently sold still requires someone to spend time
> cleaning it up a lot, which is fine if you get 20-30 mails, when you
> 1-2k mails patchwork manual interactions end up taking a large chunk
> of time. The and the fact that there is one patchwork, everyone has
> forked it to add their favourite features. Unless someone spends time
> on a reboot and goes around bringing all the forks back to a central
> line, which is is a significantly larger task than if it has been
> maintained in the first place, because now everyone has their own
> niche hacks and cool features they can't do without, but are all
> different than everyone elses.

/me puts on upstream patchwork maintainer hat

Hi!

What sort of manual interactions are you doing with patchwork and what
would you like to see changed?

You're probably using the FDO fork, so I can't help with that, but I do
try to do some work on patchwork as I get time. It's not funded so it
has to fit around my actual kernel development job, but currently we're
working on sorting out a big chunk of technical debt that should make
things a lot easier in the future, so now would be a good time to get
your requests in.

Regards,
Daniel

>
> Dave.