[PATCH] RFC: CONTRIBUTING: Embrace gitlab

[Daniel Vetter]

On Thu, Sep 13, 2018 at 10:54 AM, Jani Nikula <jani.nikula at intel.com> wrote:
> On Wed, 12 Sep 2018, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
>> On Wed, Sep 12, 2018 at 7:50 PM, Sean Paul <sean at poorly.run> wrote:
>>> On Wed, Sep 12, 2018 at 1:34 PM Lucas De Marchi
>>> <lucas.demarchi at intel.com> wrote:
>>>> - What should we do regarding the a-b, r-b? Is gitlab going to add those
>>>> automatically?
>>
>> No automation, and right now I'd suggest we squash them in and update
>> the merge request. We definitely need to squash them in for the
>> kernel, so this is also one of those thing I'd want to look into
>> automating.
>>
>>>> I would not check the 2 boxes to disallow direct pushes until those are
>>>> figured out.
>>>
>>> Given the size of this repo and the number of contributors, I'm not
>>> convinced either of these should be blockers. We should avoid merge
>>> commits since the volume is low enough that having to rebase should
>>> be quite rare. Reviews and acks will be recorded in the merge request,
>>> which is easily accessed from the UI.
>>
>> Not sure recording review&acks on the merge request is going to fly
>> for kernel. And that's kinda what I want to test-drive here, in 1st
>> gear :-)
>
> If the acks and reviews aren't recorded in git log for each commit, they
> don't exist.
>
> For submitting patches and merging them I can live with having to point
> and click on a web site.
>
> Both of those seem like something that can be automated too.
>
> But by far the biggest change that is being proposed here between the
> lines is moving code review to a gitlab web site, in a one-size-fits-all
> model. I could no longer choose and use the tools I prefer for code
> review. Tools that I can and have customized for my needs and
> preferences. I could no longer review code using the same tools I use to
> read and write code (as well as email, and pretty much everything
> else). That would be a severe performance hit for me.
>
> Perhaps I could tolerate that for maintainer-tools, but I won't endorse
> gitlab based reviews for any kernel work.
>
> With that, I think the question should be how we adapt gitlab to our
> needs, not how we adapt our needs to gitlab. How do we preserve email
> based review while trying to get as much of the benefits of gitlab as
> possible? And shouldn't the trials of (at least some of the) smaller
> projects such as maintainer-tools be taking that into account, instead
> of test driving something that won't fly in kernel?

"How to do review?" Is one of the things I want to figure out. One of
the things we _need_ to figure out, before we can roll this out more
widely. Dogfooding seems like a good way to go about that. There's
also a mail gateway somewhere, which I haven't really tried yet at all
(also I think it's not yet set up).

We could also do a middle thing, where we do both (i.e. you can do
gitlab merge request, or traditional email). And then see where people
gravitate towards.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch