[Mesa-dev] Gitlab migration

[Matt Turner]

On Sun, May 27, 2018 at 9:03 AM, Marek Olšák <maraeo at gmail.com> wrote:
> On Sun, May 27, 2018 at 10:47 AM, Jason Ekstrand <jason at jlekstrand.net>
> wrote:
>>
>> On May 26, 2018 21:03:39 Marek Olšák <maraeo at gmail.com> wrote:
>>>
>>> On Sat, May 26, 2018 at 11:13 AM, Jason Ekstrand <jason at jlekstrand.net>
>>> wrote:
>>>>
>>>> On May 25, 2018 23:43:33 Marek Olšák <maraeo at gmail.com> wrote:
>>>>>
>>>>> On Thu, May 24, 2018 at 6:46 AM, Daniel Stone <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> wrote:
>>>>>> > The 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
>>>>>
>>>>> 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).

Sort of a tangent, but for GMail there's a Chrome extension "Fixed
Width Text for Gmail" [1]

If you use a MUA like Mutt you can configure syntax highlighting. I've done it.

[1] https://chrome.google.com/webstore/detail/fixed-width-text-for-gmai/gamfbnidfgeeahogblblgafgpdhdkmib?utm_source=chrome-app-launcher-info-dialog