Re: [Ksummit-discuss] Topics for the Maintainer's Summit

[Laura Abbott <labbott@redhat.com>]

On 9/2/19 6:22 PM, Theodore Y. Ts'o wrote:
> On Tue, Sep 03, 2019 at 06:42:55AM +1000, Dave Airlie wrote:
>> On Friday, 30 August 2019, Bjorn Helgaas <helgaas@kernel.org> wrote:
>>
>>> On Thu, Aug 29, 2019 at 11:17:20PM -0400, Theodore Y. Ts'o wrote:
>>>> ...
>>>> Are there some additional topics that you'd like to suggest that we
>>>> discuss at the maintainer's summit?
>>>
>>> I don't have an effective workflow for managing incoming patches.  I
>>> use a hodge-podge of patchwork, gmail, mutt, and ugly private scripts
>>> to put patches on topic branches, review them, polish them, merge them
>>> together into a "-next" branch, generate pull requests, etc.
>>>
>>> I wish there were a collection of the workflows and scripts people
>>> use, maybe even in the kernel sources so they could be shared and
>>> improved.  Some short screencasts could help visualize and pull things
>>> together.  I know a lot of this stuff is "out there" somewhere, but
>>> I'm not aware of any organized collection.
>>
>>
>> These are quite drm specific but they do mean myself and Daniel can operate
>> seamlessly, and all i915 and drm misc maintainers and committers use the
>> same enforced workflow. We hope to move to gitlab at some point and may try
>> and use the same interface or not.
>>
>>   https://drm.pages.freedesktop.org/maintainer-tools/index.html
>>
>> Happy to give more info at maintainer summit, but we have gotten negative
>> feedback in the past from some community members who wanted to point out at
>> length that drm didnt invent group maintainership first, i still have no
>> idea of the relevancy of the comment.
> 
> Are there are other people who have interest in sharing their
> workflow?  I'm wonder if it might be useful to schedule time during
> the kernel summit, so it's open for more people to benefit from this
> sharing?  (Also note that Kernel Summit track sessions will be video
> taped for posterity, while Maintainer Summit discussions are *not*
> recorded.)

It's great that we can share these workflows but it still feels like a
bit of an anti-pattern that we even _need_ to do so. The problem is
everyone has their own 'pet' workflow and while you can certainly
adopt one, I think we're at the point where we do need something in
common for all workflows for the sake of automation (see the number
of testing topics that are about automation)

Maybe part of this discussion should be if we can't mandate a single
workflow, what parts of a maintainer workflow should be common for
the benefit of everyone?

Thanks,
Laura