Live data from Hacker News

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

101–110 of 325 posts

Re: Dear open-source maintainers, a letter from GitLab

#101
post #87
post #74

Meanwhile, Phabricator has implemented all of these (and even more). Custom templates: https://secure.phabricator.com/book/phabricator/article/form... Votes: https://www.mediawiki.org/wiki/Phabricator/Tokens It's better in almost every aspect than GitLab and GitHub. See https://en.wikipedia.org/wiki/Phabricator for an (incomplete) list of open source projects using it.

As a quite disappointed user of Gitlab (due to issues raised here, e,g, CE vs EE and the Ruby infrastructure), has anyone had experience with both? I understand that Phabricator is a more "complete" solution, but how do they compare in the core features that they both share? Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.

We've been using Phabricator for a few months, coming from private repos on Github.com. We initially liked it because it "ticked all the boxes" for the features that we needed from a source code and issue tracker. However, we ran into major issues along the way, basically because some of the concepts in Phabricator aren't compatible with our workflow. We decided to switch to Github Enterprise and haven't looked back since.

Some of the issues we had with Phabricator:

1. Phabricator is actually a suite of different applications that do specific things (e.g. source code hosting, issue tracking, project management, ...). Although Phabricator ticked all our feature boxes, some of the components it ships with are very immature and/or don't get a lot of attention from the development team.

2. For some reason the platform as a whole feels like a CRUD layer on top of a data model. The UI and various workflows in the applications are very tightly coupled with the underlying data model. I guess that makes it easy to develop and maintain the various core applications of Phabricator, but it doesn't make for a very user-friendly or usable product.

3. We have ~150 internal repositories, we actively work on ~40 of them at any given time. The source code application doesn't seem intended for that many repositories (e.g. navigating to a specific repository is non-trivial)

4. Phabricator has a fundamentally different approach to "pull requests". It works really nice, but only if you commit to using the Phabricator Way Of Doing Things. However, our team has been working on Github.com for years, and we're so used to the Github-workflow that we couldn't get used to the Phabricator workflow.

In the end Phabricator just wasn't the right tool for us. It definitely has some attractive properties: it's easy to install and upgrade, the command line tools are solid and provide all functionality you need, and it performs extremely well even on a small EC2 instance.

(EDIT: formatting)

Re: Dear open-source maintainers, a letter from GitLab

#102
post #47
post #9

With VideoLAN, we're not on github, but I believe we fit the 'large open source project' description. We host VLC, FFmpeg, x264 and quite a few related libraries. For VLC and all related VideoLAN projects, we're moving to our own instance of GitLab hosted on our infrastructure. And to be honest, it's quite good, but a few stuffs are ridiculously limited, to the point that some people in the community are resisting th…

> Finally, it's not really related, since it's more a feature request, but we'd love to allow external people to fork our repos, but not create completely new ones (or have them validated) because we don't want to host any projects under the sun (there is github and gitlab for that). So far, you either allow both features or none of them. On a technical level that seems an impossible distinction to make. Someone want…

> On a technical level that seems an impossible distinction to make.

Sure, but at least it would be clear what is 'allowed'.

Re: Dear open-source maintainers, a letter from GitLab

#103
post #9

With VideoLAN, we're not on github, but I believe we fit the 'large open source project' description. We host VLC, FFmpeg, x264 and quite a few related libraries. For VLC and all related VideoLAN projects, we're moving to our own instance of GitLab hosted on our infrastructure. And to be honest, it's quite good, but a few stuffs are ridiculously limited, to the point that some people in the community are resisting th…

Did you guys evaluate Phabricator? I wish more people knew it existed and wouldn't pick such "sideways" moves like GitHub to GitLab in an effort to be more "open source" philosophically speaking.

Yes, we did. Unfortunately, it's not really easy to help people fork the repos.

Re: Dear open-source maintainers, a letter from GitLab

#104

Any chance you can support Mercurial? There was a highly voted issue that I saw sometime back.

If you're looking for Mercurial try out RhodeCode, it support all the Mercurial specific workflows like phases etc.

RhodeCode actually supports Git, Mercurial, and Subversion.

Re: Dear open-source maintainers, a letter from GitLab

#105
post #84

Earlier quoted context omitted.

I was unaware of this. Thanks for the link. It seems just about everything is being re-written in Go these days...

Go is easier to deploy than Rubby on Fails.

Does that even matter in the world of Docker?

Re: Dear open-source maintainers, a letter from GitLab

#106
post #33

I chose Gitlab for my former company over GitHub Enterprise because we wanted an on-prem solution, and it worked well enough for ~200 folk. We did have to tweak (and occasionally break) a few things, since quite a few people suffered from NIH syndrome and wanted things done "the right way". In general, I liked it, but it always irked me that its Ruby underpinnings made it hard to upgrade/migrate stuff (we basically j…

> But today I'd probably just sign us all up for GitHub and be done with it

Did you mean Gitlab?

Re: Dear open-source maintainers, a letter from GitLab

#108
post #22
post #20

> "Right now GitLab.com is really slow and frequently down. This is because of fast growth in 2015. We are working to improve it in the first quarter in 2016. For now please consider downloading GitLab and using it on-premise for a fast experience." Is this a joke? I mean for people looking for free private Git hosting, there is Bitbucket. This statement is like saying "free, but not really, really." The fact is if I…

Have you tried using BitBucket?

I use it for personal, small scale repos where i just want to have the repo online and available across machines. Having the free, hosted tier is invaluable to me as a single developer.

That said, I've also used it in a paid, hosted environment supporting a team of 10. Again, our needs weren't overly complex and the integration with team software like Jira and Confluence were great (as can be I suppose, given the complexity of both tools).

I'm actually surprised there isn't more of a discussion around bitbucket and the cost of hosting smaller, private repos. Do most just dislike bitbucket or are you hosting bigger projects with multiple contributors which requires Github / gitlab services?

Re: Dear open-source maintainers, a letter from GitLab

#109
post #3

Their issue tracker seems really busy atm: https://i.imgur.com/Iv46xnx.png

Gr... yeah, spammers gonna spam. We're fighting it. Here you can find out more https://gitlab.com/gitlab-org/gitlab-ce/issues/5573

FYI - Users of GitLab can report spam. Click the (!) button on the offending user's profile. This triggers moderation.

Screenshot - https://twitter.com/gitlab/status/688103614556995584

Re: Dear open-source maintainers, a letter from GitLab

#110
post #33

I chose Gitlab for my former company over GitHub Enterprise because we wanted an on-prem solution, and it worked well enough for ~200 folk. We did have to tweak (and occasionally break) a few things, since quite a few people suffered from NIH syndrome and wanted things done "the right way". In general, I liked it, but it always irked me that its Ruby underpinnings made it hard to upgrade/migrate stuff (we basically j…

> But today I'd probably just sign us all up for GitHub and be done with it Did you mean Gitlab?

Nope. GitHub. In that past context, it made more sense.
Post reply on HN