On May 23, 2018 23:18:08 Kenneth Graunke <[email protected]> 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
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
