<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> </head> <body> <div dir="auto"><span style="font-family: Arial, sans-serif; font-size: 10pt;">On May 26, 2018 21:03:39 Marek Olšák <maraeo@gmail.com> wrote:</span></div><div id="aqm-original" style="font-family: sans-serif; font-size: 12pt; color: black;"><div class="aqm-original-body"><div style="color: black;"> <blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;"> <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, May 26, 2018 at 11:13 AM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><div><div class="m_2606462991167451131m_-7452738630881255109m_-2477272469205670243m_5642596053309105579m_2834839652904649092h5"> <div dir="auto"><span style="font-family:Arial,sans-serif;font-size:10pt">On May 25, 2018 23:43:33 Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote:</span></div><div id="m_2606462991167451131m_-7452738630881255109m_-2477272469205670243m_5642596053309105579m_2834839652904649092m_5312772149603265532aqm-original" style="font-family:sans-serif;font-size:12pt;color:black"><div class="m_2606462991167451131m_-7452738630881255109m_-2477272469205670243m_5642596053309105579m_2834839652904649092m_5312772149603265532aqm-original-body"><div style="color:black"> <blockquote type="cite" class="gmail_quote" style="margin:0 0 0 0.75ex;border-left:1px solid #808080;padding-left:0.75ex"> <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 24, 2018 at 6:46 AM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br> I'm going to attempt to interleave a bunch of replies here.<br> <span class="m_2606462991167451131m_-7452738630881255109m_-2477272469205670243m_5642596053309105579m_2834839652904649092m_5312772149603265532gmail-"><br> On 23 May 2018 at 20:34, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> wrote:<br> > The <a href="http://freedesktop.org" rel="noreferrer" target="_blank">freedesktop.org</a> admins are trying to move as many projects and services<br> > as possible over to gitlab and somehow I got hoodwinked into spear-heading<br> > it for mesa. There are a number of reasons for this change. Some of those<br> > reasons have to do with the maintenance cost of our sprawling and aging<br> > infrastructure. Some of those reasons provide significant benefit to the<br> > project being migrated:<br> <br> </span>Thanks for starting the discussion! I appreciate the help.<br> <br> To be clear, we _are_ migrating the hosting for all projects, as in,<br> the remote you push to will change. We've slowly staged this with a<br> few projects of various shapes and sizes, and are confident that it<br> more than holds up to the load. This is something we can pull the<br> trigger on roughly any time, and I'm happy to do it whenever. When<br> that happens, trying to push to ssh://git.fd.o will give you an error<br> message explaining how to update your SSH keys, how to change your<br> remotes, etc.<br> <br> cgit and anongit will not be orphaned: they remain as push mirrors so<br> are updated simultaneously with GItLab pushes, as will the GitHub<br> mirrors. Realistically, we can't deprecate anongit for a (very) long<br> time due to the millions of Yocto forks which have that URL embedded<br> in their build recipes. Running cgit alongside that is fairly<br> low-intervention. And hey, if we look at the logs in five years' time<br> and see 90% of people still using cgit to browse and not GitLab,<br> that's a pretty strong hint that we should put effort into keeping it.<br></blockquote><div><br></div><div>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:</div><div><a href="https://gitlab.freedesktop.org/jekstrand/mesa/commits/master" target="_blank">https://gitlab.freedesktop.org<wbr>/jekstrand/mesa/commits/master</a></div><div><br></div><div>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.<br></div><div><br></div><div>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!</div></div></div></div></blockquote></div></div></div><div dir="auto"><br></div></div></div><div dir="auto">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.</div></div></blockquote><div><br></div><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span><div dir="auto"><br></div><div id="m_2606462991167451131m_-7452738630881255109m_-2477272469205670243m_5642596053309105579m_2834839652904649092m_5312772149603265532aqm-original" style="font-family:sans-serif;font-size:12pt;color:black" dir="auto"><div class="m_2606462991167451131m_-7452738630881255109m_-2477272469205670243m_5642596053309105579m_2834839652904649092m_5312772149603265532aqm-original-body"><div style="color:black"><blockquote type="cite" class="gmail_quote" style="margin:0 0 0 0.75ex;border-left:1px solid #808080;padding-left:0.75ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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.</div></div></div></blockquote></div></div></div><div dir="auto"><br></div></span><div dir="auto">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.</div></div></blockquote><div><br></div><div>The syntax highlighting looks good.</div><div><br></div>I wonder if we can do patch reviewing via gitlab and also rebasing+pushing via gitlab (no merges), sort of what Gerrit can do.</div></div></div> </blockquote> </div> </div>  </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Given the number of people who have said they still like the mailing list, that's probably a discussion for another email thread.</div></body> </html>