Wikimedia is moving to Gitlab • Hacker News Board

Re: Wikimedia is moving to Gitlab

#391

Post by gaba » Thu, Oct 29, 2020, 7:36 PM UTC

phikai wrote: post #117

jancsika wrote: post #53

Anyone thinking of moving to their own Gitlab instance with Gitlab CE-- either stay on Github or prepare to waste your time dealing with user spam bots that pollute your site's search results. In other words-- if you want the common use case for a FOSS project: 1. publicly viewable main repository with publicly viewable issue tracker 2. requirement to log in to view all snippets, user profiles, perhaps even other rep…

Hi! I'm the PM at GitLab who works on Snippets, so thanks for providing this feedback. We do have Recaptcha support which can be configured - are you seeing these kinds of issues with that enabled/configured? One item that is on the roadmap that is coming and may be of interest is `Optional Admin Approval for local user sign up` - https://gitlab.com/groups/gitlab-org/-/epics/4491 . I'm not in the group working on tha…

Is this something that we will have in the CE version (the open licensed one) or it will only go to the enterprise one?

Re: Wikimedia is moving to Gitlab

#392

Post by kevincox » Thu, Oct 29, 2020, 7:50 PM UTC

epriest wrote: post #390

kevincox wrote: post #388

Earlier quoted context omitted.

I don't need perfect, I just need good. GitHub and GitLab both have good implementations as well as every other good code review system I have used. GitHub annoying tries its hardest to hide the "outdated" comments but GitLab has the option to keep them open (they are no longer visible in the code, but remain on the discussion tab) So I appreciate your opinion that it is impossible, but as a reviewer I much prefer wh…

GitHub's implementation does not do what you claim it does. GitHub has no behavior around porting and placing comments (while Phabricator does), GitHub just hides anything it can't place exactly. See my link above for a detailed description of GitHub's very simple implementation. I believe this is absolutely the wrong tradeoff.

I use GitHub every day, I've definitely seen it preserve some comments. Sure, it drops a lot. But I still prefer this to dropping them all, or showing the comments on the wrong lines.

Re: Wikimedia is moving to Gitlab

#393

Post by brennen » Thu, Oct 29, 2020, 8:46 PM UTC

pbronez wrote: post #373

brennen wrote: post #185

Earlier quoted context omitted.

> I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. A few paragraphs I recently wrote elsewhere: The entire state of code forges as a general thing in 2020 is all the evidence you could possibly want that version control systems (Git, I'm talking about Git) are themselves massively deficient in desi…

> an entire class of argument [...] mostly vanish if the underlying data model in the de facto standard was rich enough to support the actual work of software development. Interesting idea. You think we could develop a unified data model that covers source code, static files, documentation, project management and community management as a single unified thing? That’s certainly ambitious, and I’d love to see it. For t…

> You think we could develop a unified data model that covers source code, static files, documentation, project management and community management as a single unified thing?

Realistically, not exactly, given how much space some of those things cover.

I do think that entities like code review are as much a part of the history of a project as the deltas to code. Reviews not being first-class objects in the VCS itself has turned out to be a crack into which you can wedge an entire GitHub.

I won't claim I know where best to draw the line here. Better handling of large static files by default and a robust way to model relationships between projects obviously belong within the VCS. On the other hand, relationships modeled in issue tracking systems and the like are also part of the software's history, but past some level of complexity it gets much harder to imagine wedging them into something that you can pass around like you clone a Git repo. All I can really say for sure is that it feels broken that all of this stuff lives in competing application silos.

(As a sidebar: Not that you can't jam things like review data into git-as-data-store. Gerrit does just that. But nobody's going to mistake that for a usable interface to code review.)

Anyhow, I don't think you're wrong about the social & economic factors, but I think a different landscape with less concentration of power could have shaken out if (for example) easy code review had been baked in and host-agnostic early on. Fully p2p architectures aren't feasible, or even necessarily desirable, for a lot of problems - but it shouldn't be too much to ask that things are able to be federated and resistant to capture by a single vendor.

> Still... I completely agree that it would be awesome to have a more self-sovereign computing architecture writ large. I’m just pessimistic we can get there from here.

Yeah, fair enough. I am myself boundlessly pessimistic about the future of computing generally.

Re: Wikimedia is moving to Gitlab

#394

Post by dnsmichi » Thu, Oct 29, 2020, 8:50 PM UTC

coder543 wrote: post #385

dnsmichi wrote: post #384

Earlier quoted context omitted.

Iterating on my original thought, here is a smaller feature request for self-hosted GitLab instances. This can help GitLab.com too: https://gitlab.com/gitlab-org/gitlab/-/issues/273618

I still think an even better path to success is to allow entirely disabling linking for non-admins. Google no longer treats "nofollow" as strongly as it used to: https://webmasters.googleblog.com/2019/09/evolving-nofollow-...

Thanks for sharing, I have added it to the issue, maybe you want to join the discussion there :) https://gitlab.com/gitlab-org/gitlab/-/issues/273618#note_43...

Just so that I can follow - URLs posted by non-admins should not render as HTML URLs at all? Wouldn't that be quite limiting for OSS project members for example?

Re: Wikimedia is moving to Gitlab

#395

Post by coder543 » Thu, Oct 29, 2020, 8:58 PM UTC

dnsmichi wrote: post #394

coder543 wrote: post #385

Earlier quoted context omitted.

I still think an even better path to success is to allow entirely disabling linking for non-admins. Google no longer treats "nofollow" as strongly as it used to: https://webmasters.googleblog.com/2019/09/evolving-nofollow-...

Thanks for sharing, I have added it to the issue, maybe you want to join the discussion there :) https://gitlab.com/gitlab-org/gitlab/-/issues/273618#note_43... Just so that I can follow - URLs posted by non-admins should not render as HTML URLs at all? Wouldn't that be quite limiting for OSS project members for example?

My opinion on the topic isn't definitive by any means, but I think a lot of projects would do just fine without allowing arbitrary hyperlinks to be added by non-admins.

I think being able to link to related issues and link into the code is still important, for example.

It's certainly a trade off, but spammers want it to be rendered as a link.

Re: Wikimedia is moving to Gitlab

#396

Post by epriest » Thu, Oct 29, 2020, 9:02 PM UTC

kevincox wrote: post #392

epriest wrote: post #390

Earlier quoted context omitted.

GitHub's implementation does not do what you claim it does. GitHub has no behavior around porting and placing comments (while Phabricator does), GitHub just hides anything it can't place exactly. See my link above for a detailed description of GitHub's very simple implementation. I believe this is absolutely the wrong tradeoff.

I use GitHub every day, I've definitely seen it preserve some comments. Sure, it drops a lot. But I still prefer this to dropping them all, or showing the comments on the wrong lines.

I mean that GitHub does not "try", in the sense of looking at the interdiff, doing fuzzy matching, trying to identify line-by-line similarity, etc. It places comments only if the hunk is exactly unchanged and gives up otherwise.

Phabricator does "try", in the sense that it examines the interdiff and attempts (of course, imperfectly, because no implementation can be perfect) to track line movement across hunk mutations.

My claim is that all comments which GitHub places correctly, Phabricator also places correctly. And some comments which GitHub drops, Phabricator places correctly (on the same line a human would select)! However, some comments which GitHub drops, Phabricator places incorrectly (on a line other than the line a human would select).

So the actual implementation you prefer is not one that tries, but one that doesn't try! Phabricator could have approximately GitHub's behavior by just deleting a bunch of code.

That's perfectly fine: many other users also prefer comments be discarded rather than tracked to a possibly-wrong line, too. I strongly believe this isn't a good behavior for code review software, which is why Phabricator doesn't do it -- but Phabricator puts substantially more effort into trying to track and place comments correctly than GitHub does.

Re: Wikimedia is moving to Gitlab

#397

Post by nuritzi » Thu, Oct 29, 2020, 9:56 PM UTC

epage wrote: post #345

WrtCdEvrydy wrote: post #181

Earlier quoted context omitted.

Phabricator is amazing as an all-in-one solution for a small shop.

I'm curious about this because I've wanted to get off Phab as soon as I started using it - Whats your thoughts on "arc"? It seems like a whole can of worms of problems you can run into with basic branch flows. I know teams that have complex branch flows and it is a nightmare. Same for Windows users. - What do you use for a CI? How well does the integration work for you? - How is it with tracking conversations on Diff…

@epage -- Unfortunately I can't speak to the branch flow or bots question. Perhaps someone else here can? Other answers are below.

-- Re: CI -- We dogfood GitLab CI via gitlab.com -- so no need for integrations.

GitLab non-engineering teams use CI all the time because we constantly update the handbook to document all of our work.

I would love to see this practice more often in OSS orgs, and other companies for that matter. Having a handbook-first approach (https://about.gitlab.com/company/culture/all-remote/handbook...) really helps enable remote team collaboration and makes it easier for newcomers to jump in. I think OSS orgs have done a good job of recognizing the importance of documentation for development projects, but there's an opportunity to increase documentation around workflows and community operations.

-- Re: tracking conversations on Diffs -- Admittedly, I don't have a lot of experience with this outside of GitLab. But maybe that's the point. It's easy to chime in on diffs on merge requests on GitLab, and one of my favorite features is "suggesting changes" where you can add in a suggested update to a diff and the author can choose whether or not to apply it.

Here's a link with info about suggested changes: https://docs.gitlab.com/ee/user/discussions/#suggest-changes

It's within the larger doc addressing discussions in GitLab in general: https://docs.gitlab.com/ee/user/discussions/

-- Btw, for anyone interested, here's more info on using GitLab for project management:

- https://about.gitlab.com/solutions/project-management/ - https://www.buggycoder.com/project-management-with-gitlab/ - https://thenewstack.io/gitlab-issue-board-project-management...

I gave a presentation about cross-functional team collaboration using GitLab at GNOME's GUADEC this year. Here are the slides: https://events.gnome.org/event/1/contributions/70/ .. As a program manager, I'm generally really excited about this topic!

-- Some of the features I talk about are not available as part of the Community Edition, but there's the GitLab for Open Source program which gives OSS projects access to our top tiers, plus 50K CI mins per month, for free.

I'm hoping to make the program's page more discoverable, but in the meantime, here's the link: https://about.gitlab.com/solutions/open-source/

Re: Wikimedia is moving to Gitlab

#398

Post by AaronFriel » Thu, Oct 29, 2020, 10:36 PM UTC

u801e wrote: post #310

AaronFriel wrote: post #303

Earlier quoted context omitted.

You aren't a special case, but if you don't see any flaws with your method of code review then I don't think you're the target market for code review tools.

Now you're claiming that I'm making an argument that I never made. To be clear, the original statement was whether there was a better review tool compared to Gerrit for those who review code and use that tool for that purpose. I responded by suggesting the patch review via mailing list method and asked a follow up question about how Gerrit handled related commits and explained how that case was handled by the mailing…

I'm sorry I was rude to you, I didn't mean that and I apologize.

I didn't mean anything more than what I literally wrote, which is I don't think you're the target market for code review tools and your suggestion may not be a good fit for people looking for review tools.

Re: Wikimedia is moving to Gitlab

#399

Post by huskyr » Thu, Oct 29, 2020, 11:44 PM UTC

lawtalkinghuman wrote: post #51

badrequest wrote: post #34

Earlier quoted context omitted.

You're okay with the tool being difficult to use because you already know how to use it.

I'm okay with Vim being slightly harder to learn to use than VS Code. A tougher learning curve in exchange for more powerful tools can be a good tradeoff.

I think this is a good comparison, and exactly shows the problem: Vim is only used by a minority of developers, the majority use some kind of graphical editor (like VS Code). That doesn't mean learning Vim isn't a good tradeoff, it's just not a good tradeoff for the majority of people.

Re: Wikimedia is moving to Gitlab

#400

Post by brennen » Fri, Oct 30, 2020, 3:03 AM UTC

judge2020 wrote: post #317

brennen wrote: post #185

Earlier quoted context omitted.

> I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. A few paragraphs I recently wrote elsewhere: The entire state of code forges as a general thing in 2020 is all the evidence you could possibly want that version control systems (Git, I'm talking about Git) are themselves massively deficient in desi…

To me, it sounds like the issue is that you need a central source of truth that everyone can pull from for their purposes, and distributing the code review part doesn't sound like it'll add much. In the current climate, most anyone requesting code review is probably trying to merge into the main central source of truth anyways, so what actual benefit does it bring to either the maintainers or the contributors?

Version control for a genuinely long-lived project is a problem that often outlasts:

- Dominant version control and code review system(s) / paradigms.

- The current configuration of institutional owners.

- Users' trust in an owner / sponsor / maintainer. (Forks happen for reasons.)

- The involvement of developers who remember why and how decisions were made.

- The trustworthiness of the entities that control services, applications, and network real estate used for development.

Some central source of truth is usually necessary, but maintainers and contributors don't benefit when that source of truth is subject to vendor lock-in or can otherwise only migrate at great cost. For all the collaborative benefit that GitHub has undeniably wrought, platform monopolies are eventually a failure mode for end users, at least as for-profit enterprises. With the exception of the dominant silo vendors, nobody in the ecosystem really benefits from being forced to choose a silo that will be hard (and lossy) to escape later. The silos are engineered to limit mobility and channel interoperability to their own ends, for business reasons that run directly contrary to the interests of their users.

If the protocol at hand were actually up to the task, we'd spend less effort and anxiety on the problems of all the non-protocol platform tooling that's been built up around it.