[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)
Cheers,
Nicolai
>
> 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