[Mesa-dev] Gitlab migration

[Tapani Pälli]

On 05/24/2018 09:31 AM, Jason Ekstrand wrote:
> 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.
> 

It's possible to also just decide not use the 'merge button'. Within 
Android-IA scope it was decided to manually push commits and just close 
pull requests when pushing to keep git history clean.

// Tapani