On Sun, May 27, 2018 at 9:03 AM, Marek Olšák <mar...@gmail.com> wrote: > On Sun, May 27, 2018 at 10:47 AM, Jason Ekstrand <ja...@jlekstrand.net> > wrote: >> >> On May 26, 2018 21:03:39 Marek Olšák <mar...@gmail.com> wrote: >>> >>> On Sat, May 26, 2018 at 11:13 AM, Jason Ekstrand <ja...@jlekstrand.net> >>> wrote: >>>> >>>> On May 25, 2018 23:43:33 Marek Olšák <mar...@gmail.com> wrote: >>>>> >>>>> On Thu, May 24, 2018 at 6:46 AM, Daniel Stone <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> 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
