[Mesa-dev] Gitlab migration
maraeo at gmail.com
Sun May 27 04:02:57 UTC 2018
On Sat, May 26, 2018 at 11:13 AM, Jason Ekstrand <jason at jlekstrand.net>
> 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>
>>> 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
>>> > as possible over to gitlab and somehow I got hoodwinked into
>>> > it for mesa. There are a number of reasons for this change. Some of
>>> > reasons have to do with the maintenance cost of our sprawling and aging
>>> > infrastructure. Some of those reasons provide significant benefit to
>>> > 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:
>> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev