[Mesa-dev] Gitlab migration

Nicolai Hähnle nhaehnle at gmail.com
Mon May 28 09:36:20 UTC 2018

On 27.05.2018 18:03, Marek Olšák wrote:
> On Sun, May 27, 2018 at 10:47 AM, Jason Ekstrand <jason at jlekstrand.net 
> <mailto:jason at jlekstrand.net>> wrote:
>     On May 26, 2018 21:03:39 Marek Olšák <maraeo at gmail.com
>     <mailto:maraeo at gmail.com>> wrote:
>>     On Sat, May 26, 2018 at 11:13 AM, Jason Ekstrand
>>     <jason at jlekstrand.net <mailto:jason at jlekstrand.net>> wrote:
>>         On May 25, 2018 23:43:33 Marek Olšák <maraeo at gmail.com
>>         <mailto:maraeo at gmail.com>> wrote:
>>>         On Thu, May 24, 2018 at 6:46 AM, Daniel Stone
>>>         <daniel at fooishbar.org <mailto:daniel at fooishbar.org>> wrote:
>>>             Hi all,
>>>             I'm going to attempt to interleave a bunch of replies here.
>>>             On 23 May 2018 at 20:34, Jason Ekstrand
>>>             <jason at jlekstrand.net <mailto:jason at jlekstrand.net>> wrote:
>>>             > 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 starting the discussion! I appreciate the help.
>>>             To be clear, we _are_ migrating the hosting for all
>>>             projects, as in,
>>>             the remote you push to will change. We've slowly staged
>>>             this with a
>>>             few projects of various shapes and sizes, and are
>>>             confident that it
>>>             more than holds up to the load. This is something we can
>>>             pull the
>>>             trigger on roughly any time, and I'm happy to do it
>>>             whenever. When
>>>             that happens, trying to push to ssh://git.fd.o will give
>>>             you an error
>>>             message explaining how to update your SSH keys, how to
>>>             change your
>>>             remotes, etc.
>>>             cgit and anongit will not be orphaned: they remain as
>>>             push mirrors so
>>>             are updated simultaneously with GItLab pushes, as will
>>>             the GitHub
>>>             mirrors. Realistically, we can't deprecate anongit for a
>>>             (very) long
>>>             time due to the millions of Yocto forks which have that
>>>             URL embedded
>>>             in their build recipes. Running cgit alongside that is fairly
>>>             low-intervention. And hey, if we look at the logs in five
>>>             years' time
>>>             and see 90% of people still using cgit to browse and not
>>>             GitLab,
>>>             that's a pretty strong hint that we should put effort
>>>             into keeping it.
>>>         Well, I don't know what people are talking about. A cgit
>>>         commit log is a tight table with 5 columns with information.
>>>         I can't find anything like that in GitLab. All I could find
>>>         is this:
>>>         https://gitlab.freedesktop.org/jekstrand/mesa/commits/master
>>>         <https://gitlab.freedesktop.org/jekstrand/mesa/commits/master>
>>>         The elements are too large and don't have much information.
>>>         Why would you have the author name on another line when you
>>>         could add another column instead? There is a lot of unused
>>>         screen space. And why having avatars in the commit log. It's
>>>         not Facebook.
>>>         Then there is the project Overview page. It mostly just shows
>>>         files in the top level directory. Compare it with cgit where
>>>         the Overview page looks like a, guess what, overview!
>>         GitLab's "branches" page is sort of the same thing but with
>>         GitLab's more chunky style.  They make the same choice as
>>         GitHub to have the homepage be there for browser and the
>>         project's readme.  (You have to name it README.md for that to
>>         work).  It makes sense on GitHub because that's all many
>>         projects have for a home page.  Given that most Mesa people
>>         who go to the web view are doing so to find a particular
>>         branch and read the commit log, it may not be the optimal choice.
>>     I think the more fitting word is chubby. Good for mobile and touch
>>     screens. Not so good for mouse-navigated high-resolution screens
>>     (typical office setup).
>>>         OK, that was harsh, but there is a lot of truth to it. I
>>>         guess GitLab is great for admins and I get that. Speaking of
>>>         the web UI, at least the read-only view is impressively
>>>         unimpressive.
>>         Perhaps part of the reason why I like the GitLab UI so much is
>>         because I'm a crazy person who regularly uses it from my
>>         phone.  When you open the two on a mobile device, the
>>         difference in usability is night and day.  I also spend a lot
>>         of time in the file viewer and really like syntax highlighting.
>>     The syntax highlighting looks good.
>>     I wonder if we can do patch reviewing via gitlab and also
>>     rebasing+pushing via gitlab (no merges), sort of what Gerrit can do.
>     We can disallow actual merges and only allow fast-forward merges. 
>     I'm not sure if our version will do the rebase for you or if you
>     have to do it yourself and force-push the branch prior to merging. 
>     In any case, we can get the merge request workflow without ending up
>     with merges in the history.
>     Given the number of people who have said they still like the mailing
>     list, that's probably a discussion for another email thread.
> Well, I have a little bit of experience with Phabricator and Gerrit, and 
> they are great tools for reviewing. I think that a mailing list is the 
> worst option when comes to comfort (no syntax highlighting, the font 
> isn't monospace).

It is monospace for me. Native e-mail clients for the win :P

I do agree though that those web tools can be quite nice for reviews, 
with two big caveats:

- many of them really suck for patch series (this is my main gripe with 
Phabricator for LLVM)

- they tend to be really slow (this is my main gripe with Gerrit at Khronos)


> Marek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.

More information about the mesa-dev mailing list