[Mesa-dev] Gitlab migration

[Kenneth Graunke]

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...

Maybe that's what you were getting at.  I think discipline can avoid
that, but we'd have to be intentional about it...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180523/92265eab/attachment.sig>