[Mesa-dev] Gitlab migration
Jason Ekstrand
jason at jlekstrand.net
Thu May 24 06:31:20 UTC 2018
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
More information about the mesa-dev
mailing list