On 27.05.2018 18:03, Marek Olšák wrote:
On Sun, May 27, 2018 at 10:47 AM, Jason Ekstrand <ja...@jlekstrand.net
<mailto:ja...@jlekstrand.net>> wrote:
On May 26, 2018 21:03:39 Marek Olšák <mar...@gmail.com
<mailto:mar...@gmail.com>> wrote:
On Sat, May 26, 2018 at 11:13 AM, Jason Ekstrand
<ja...@jlekstrand.net <mailto:ja...@jlekstrand.net>> wrote:
On May 25, 2018 23:43:33 Marek Olšák <mar...@gmail.com
<mailto:mar...@gmail.com>> wrote:
On Thu, May 24, 2018 at 6:46 AM, Daniel Stone
<dan...@fooishbar.org <mailto:dan...@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
<ja...@jlekstrand.net <mailto:ja...@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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
