[PATCH] RFC: CONTRIBUTING: Embrace gitlab

[Jani Nikula]

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?


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center