On Wednesday, May 23, 2018 1:58:14 PM PDT Nicolai Hähnle wrote: > Hi Jason, > > On 23.05.2018 21:34, Jason Ekstrand wrote: > > Mesa developers, > > > > tl;dr. Please go to gitlab.freedesktop.org > > <http://gitlab.freedesktop.org>, create your account, and upload your > > SSH keys. Instructions are the bottom of this e-mail. > > > > 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 doing this! I agree that this should be quite beneficial > overall, and getting the account set up was painless. > > > > * Project-led user/rights management. If we're on gitlab, project > > maintainers can give people access and we no longer have to wait for the > > freedesktop admins to add a new person. And the freedesktop admins > > don't have to take the time. > > > > * Better web UI for git. Ok, so some people will argue with me on > > this one but it's at least how I feel. :-) > > > > * [Optional] Integrated commit history and issue tracking. Bugzilla > > tags are great but gitlab ties things together much better. > > I'd be in favor of moving the issue tracking.
FWIW, I'm less convinced that moving away from Bugzilla is a good idea. It might be, I just don't know yet. > > * [Optional] Merge-request workflow. With the rise of github, there > > are many developers out there who are used to the merge-request workflow > > and switching to that may lower the barrier to entry for new contributors. > > I admit that it's been a while since I checked, but the web-based merge > workflows of GitHub and GitLab were (and probably still are) atrocious, > so please don't. > > The tl;dr is that they nudge people towards not cleaning up their commit > history and/or squashing everything on the final commit, and that's just > a fundamentally bad idea. > > The one web-based review interface I know of which gets this right is > Gerrit, since it emphasizes commits over merges and has pretty good > support for commit series. One really nice thing is that it actually has a view of outstanding patch series, that's properly tied to things getting committed, unlike patchwork which is only useful if people bother to curate their series' status. I'm struggling to keep up with mesa-dev these days, despite it being my day job. Having a page with the series outstanding might make life easier for reviewers, and also make it easier for series not to get lost and fall through the cracks... Mechanically, it also had pretty reasonable support for multiple patch series, updating a previous one automatically (IIRC). One thing I hated about using Gitlab for the CTS is that every series created merges, littering the history...and worse, people got in the habit of only explaining their work in the pull request, which became the merge commit message. People didn't bother giving individual commits meaningful explanations. That made 'git blame' harder, as you had to blame then look for the merge...makes bisects messier too... Maybe that's what you were getting at. I think discipline can avoid that, but we'd have to be intentional about it...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
