[Mesa-dev] Gitlab migration

[Daniel Vetter]

On Thu, May 24, 2018 at 8:18 AM, 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...
>
> Maybe that's what you were getting at.  I think discipline can avoid
> that, but we'd have to be intentional about it...

A lot of these expectations are pretty easy to check with a few simple
scripts, integrated as one of the CI steps. It's what we're doing on
the kernel side to appease the endless amounts of bikesheds around
what commits should look like, using a combo of bash scripts and
patchwork.

patchwork is a pain since the loss of semantic meaning is really hard
to construct, and client side scripts are a pain because it's yet
another arbitrary barrier to jump over as a contributor. It's better
than nothing, but personally I have really high hopes of moving a lot
of the CI stuff over to gitlab. And that means all the things, from
basic commit checking (all commits have the right amount of
signe-off-by lines from the right people), build testing (that's a
royal pain on the kernel) and actual functional testing (i.e. tying
our kernel CI into it). Long term at least.

Very, very, very long term most likely :-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch