Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wikimedia is moving to Gitlab

mediawiki.org

Post reply on HN
Print view View original

331–340 of 408 posts

Re: Wikimedia is moving to Gitlab

#331

Post by pengaru »

nichos wrote: post #321
pengaru wrote: post #319

I'll generally support using gitlab over github on principle, but have found gitlab to be basically useless without javascript enabled while github still kind of works at least for read-only visiting of shared github URLs. Whenever someone shares a gitlab URL with me, it's very rare I can make any use of it without enabling js, it's quite annoying.

Of a simple page that works without JavaScript enabled is of interest to you, you might want to check out sourcehut.

If I could compel everyone migrating to gitlab to instead use sourcehut, I would.

Alas this isn't about my personal choice of git hosting, I already have my needs covered with a dedicated server.

Re: Wikimedia is moving to Gitlab

#332

Post by bawolff »

q3k wrote: post #14
huskyr wrote: post #10

Earlier quoted context omitted.

I guess you can get the hang of Gerrit, but i tried it out a couple of times (i occasionally do work on projects in the Wikimedia git repo) and is pretty evident that the interface is written by developers with little knowledge of user experience. Moving stuff to Gitlab will probably increase the number of volunteer contributions, at least i'm more interested in contributing more now.

I really don't mind the Gerrit UX - it seems to be optimized for daily use by programmers, not for onboarding speed. That's a tradeoff I'm very much okay with.

Gerrit ux is full of bugs that get in the way of daily use (maybe improved over time). Things like overriding ctrl-f in the browser but then having the overriden search bar not work or not being able to effectively type inline comments on mobile.

I dont really think the choices that they did make that work, are really any better in optimized daily use than intuitive choices would have been.

(Yes probably much of this is fixed)

Re: Wikimedia is moving to Gitlab

#333

Post by gerdesj »

Things move so fast! git was initially developed on the back of a fag (cigarette) packet by Mr Torvalds and his mates for Linux code development. It seems to work quite well because we have a lot of gits these days.

github or lab or gerrit? I don't have favourite but I did notice a lot more coloured lines with gerrit stuff and a feeling of bewilderment. However I also felt like the adults seemed to know what was going on.

Let's see how this pans out. It'll probably be fine but I suspect we will lose something by creeping towards the "mainstream" and ignoring diversity. That sounds a bit odd for a tool designed for Linux 8)

Re: Wikimedia is moving to Gitlab

#334

Post by bawolff »

20after4 wrote: post #160
q3k wrote: post #14

Earlier quoted context omitted.

I really don't mind the Gerrit UX - it seems to be optimized for daily use by programmers, not for onboarding speed. That's a tradeoff I'm very much okay with.

Gerrit is so off-putting to new users that many never get over the learning curve. At Wikimedia we want to be welcoming to new contributors. We also have to consider the on-boarding experience of new staff members, as well as the productivity of staff and long-time contributors. Gerrit satisfies some people who have used it for a long time but it is almost universally disliked by newcomers. When your users are volunt…

I'm personally somewhat doubtful that that is really the aspect of the new dev experience at wikimedia that is actually turning off newbies.

Re: Wikimedia is moving to Gitlab

#335

Post by waheoo »

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…

Gerrit handles related commits in a similar way I guess.

A Gerrit changeset is like a GitHub pr, it has many commits, and commits are usually rebased against master, this is crucial to track the review properly over time. (Its very easy to switch to earlier revisions of the same changeset and you never see external changes.)

Honestly, I don't think Gerrit is anything special, I think it simply has the right approach to development (rebased/ff-only) that enables easy review.

Re: Wikimedia is moving to Gitlab

#336

Post by bawolff »

easton wrote: post #262
bredren wrote: post #186

Earlier quoted context omitted.

I was able to see Wikipedia uses something called openstack, but not the details of what infrastructure they host on. Anyone know what facilities these repos will ultimately be served from?

Wikimedia uses colocated boxes around the world at different providers, and the user facing stuff is backed by Cloudflare. https://meta.wikimedia.org/wiki/Wikimedia_servers

The user facing stuff is not backed by cloudflare (Cloudflare's magic transit has at some points been used to mitigate DDOS attacks at the IP layer, but otherwise cloudflare is not used. Wikimedia operates (its own) varnish servers in virginia, texas, san francisco, singapore and amsterdam to do frontend caching.)

Re: Wikimedia is moving to Gitlab

#337

Post by meibo »

encom wrote: post #145
rightbyte wrote: post #137

Earlier quoted context omitted.

Relying on Google's Spying-as-a-Service tooling is not very FOSS at all. There need to be other ways to reach out to users who block Google.

I immediately back out whenever encounter Recaptcha. The other day I was forced to endure it, because I wanted to delete my ancient Minecraft account, since Microsoft pulled a Facebook and are going to require a Microsoft account to play going forwards. Without exaggeration, it took me 15 minutes of training Google surveillance AI (had to solve it three times), for Recaptcha to let me in. I guess Google really hates…

You're doing something very wrong if you take 15 minutes to solve these and aren't on Tor. Even on public VPN and Firefox this doesn't happen usually. I know people that pick the wrong options to fuck with their models though, and then go on HN to complain about recaptcha being annoying.

Re: Wikimedia is moving to Gitlab

#338

Post by bawolff »

bredren wrote: post #186
detaro wrote: post #32

Earlier quoted context omitted.

They're selfhosting.

I was able to see Wikipedia uses something called openstack, but not the details of what infrastructure they host on. Anyone know what facilities these repos will ultimately be served from?

Openstack is used for wikimedia cloud, which is a project to give volunteers compute resources to do cool projects (this includes domains wmcloud.org toolserver.org and wmflabs.org). Production does not use openstack.

Things like code review tools would be hosted in Virginia [eqiad] (with backup in texas [codfw]) on hardware owned by the Wikimedia Foundation.

Docs about how gerrit is hosted https://wikitech.wikimedia.org/wiki/Gerrit if you want to know nitty gritty details see also https://github.com/wikimedia/puppet

Re: Wikimedia is moving to Gitlab

#339

Post by mushakov »

jancsika wrote: post #228
mushakov wrote: post #179

Earlier quoted context omitted.

Hi! I'm a PM at GitLab. Please see my reply above for more details but TL;DR we shipped the first iteration of the `Optional Admin Approval for local user sign up` feature in 13.5. I'd love your feedback! Please comment on the epic if there are other changes for this feature that would help your use case https://gitlab.com/groups/gitlab-org/-/epics/4491

Thanks for the update. I can certainly manage user sign-up from the admin tab for the time being. Once it's hooked into email, I believe that will make things maintainable again for me. From a UX standpoint it's still sub-par. Someone who wants to report an issue doesn't want to wait an arbitrary amount of time to be allowed to report an issue. They are ready to report it at that moment. And as an admin, I don't want…

That's a really interesting idea! Users could have limited interactions with the instance and content queued up until approved by an administrator. I created an issue to capture this. https://gitlab.com/gitlab-org/gitlab/-/issues/273542

Re: Wikimedia is moving to Gitlab

#340

Post by zzzeek »

bawolff wrote: post #322
zzzeek wrote: post #116

I think I have some relevant experience here. We host all of our projects on github: https://github.com/sqlalchemy/ yet we also use gerrit! https://gerrit.sqlalchemy.org/ users send us pull requests, and they never have to deal with Gerrit ever. We use a custom integration, the source code to which is here: https://github.com/sqlalchemyorg/publishthing/tree/master/pu... and then we mostly bidirectional synchronizatio…

Wikimedia was already using mirroring to github (however we didn't accept pull requests). I'm pretty sure most of the anti-gerrit sentiment at wikimedia was about gerrit as a code review tool. My personal experience with it (as a mediawiki developer) is gerrit has a lot of UI bugs (although it has gotten better). I also suspect it encourages a code review culture that is overly nitpicky and risk averse (but perhaps t…

I'm not familiar with any UI bugs of any kind, but we don't use the "live editing" feature, maybe that's where you had problems. The big issue with Gerrit is on the "getting plugins to work" side of things, as they are kind of ad-hoc and almost totally undocumented, as well as the access model is too complicated but once that's all working, there is no need to deal with it.

nitpicky culture, we maybe have that problem with Openstack where there are thousands of developers, but for our projects in SQLAlchemy we're a team of about five people and I'm more or less a BDFL type of role, to the degree that we are nitpicky about things it only prevents much bigger problems from happening later, if a review has little things that are bugging me I'll just fix them myself and push a new change up rather than bothering them with it, also something you can't usually do with pull requests.

Post reply on HN