[Mesa-dev] Gitlab migration

[Jason Ekstrand]

On May 23, 2018 23:18:08 Kenneth Graunke <kenneth at whitecape.org> wrote:

> On Wednesday, May 23, 2018 1:58:14 PM PDT Nicolai Hähnle wrote:
>> Hi Jason,
>>
>> On 23.05.2018 21:34, Jason Ekstrand wrote:
>>> Mesa developers,
>>>
>>> tl;dr.  Please go to gitlab.freedesktop.org
>>> <http://gitlab.freedesktop.org>, create your account, and upload your
>>> SSH keys.  Instructions are the bottom of this e-mail.
>>>
>>> The freedesktop.org <http://freedesktop.org> admins are trying to move
>>> as many projects and services as possible over to gitlab and somehow I
>>> got hoodwinked into spear-heading it for mesa.  There are a number of
>>> reasons for this change.  Some of those reasons have to do with the
>>> maintenance cost of our sprawling and aging infrastructure.  Some of
>>> those reasons provide significant benefit to the project being migrated:
>>
>> Thanks for doing this! I agree that this should be quite beneficial
>> overall, and getting the account set up was painless.
>>
>>
>>> * Project-led user/rights management.  If we're on gitlab, project
>>> maintainers can give people access and we no longer have to wait for the
>>> freedesktop admins to add a new person.  And the freedesktop admins
>>> don't have to take the time.
>>>
>>> * Better web UI for git.  Ok, so some people will argue with me on
>>> this one but it's at least how I feel. :-)
>>>
>>> * [Optional] Integrated commit history and issue tracking.  Bugzilla
>>> tags are great but gitlab ties things together much better.
>>
>> I'd be in favor of moving the issue tracking.
>
> FWIW, I'm less convinced that moving away from Bugzilla is a good idea.
>
> It might be, I just don't know yet.
>
>>> * [Optional] Merge-request workflow.  With the rise of github, there
>>> are many developers out there who are used to the merge-request workflow
>>> and switching to that may lower the barrier to entry for new contributors.
>>
>> I admit that it's been a while since I checked, but the web-based merge
>> workflows of GitHub and GitLab were (and probably still are) atrocious,
>> so please don't.
>>
>> The tl;dr is that they nudge people towards not cleaning up their commit
>> history and/or squashing everything on the final commit, and that's just
>> a fundamentally bad idea.
>>
>> The one web-based review interface I know of which gets this right is
>> Gerrit, since it emphasizes commits over merges and has pretty good
>> support for commit series.
>
> One really nice thing is that it actually has a view of outstanding
> patch series, that's properly tied to things getting committed, unlike
> patchwork which is only useful if people bother to curate their series'
> status.  I'm struggling to keep up with mesa-dev these days, despite it
> being my day job.  Having a page with the series outstanding might make
> life easier for reviewers, and also make it easier for series not to get
> lost and fall through the cracks...
>
> Mechanically, it also had pretty reasonable support for multiple patch
> series, updating a previous one automatically (IIRC).
>
> One thing I hated about using Gitlab for the CTS is that every series
> created merges, littering the history...and worse, people got in the
> habit of only explaining their work in the pull request, which became
> the merge commit message.  People didn't bother giving individual
> commits meaningful explanations.  That made 'git blame' harder, as
> you had to blame then look for the merge...makes bisects messier too...

There is a per-repo setting for what kind of merge requests are allowed and 
one option is to only allow fast-forward merges.  I think there's also an 
option to automatically rebase the branch prior to merging.  That doesn't 
enforce good commit messages but it does kill the merge commits.

--Jason