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

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

Post reply on HN
Print view View original

91–100 of 325 posts

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

#91

Post by [deleted] »

throwaway999888 wrote: post #71
glandium wrote: post #5

Just for this, I'm tempted: One issue that was raised several times was the ability to not create merge commits. In GitLab you can, as an alternative to the merge commits, use fast-forward merges or have merge requests be automatically rebased. The main thing keeping me from actually doing it is the network effect... and this: Disadvantages Right now GitLab.com is really slow and frequently down. This is because of f…

There is already built-in support for pull request[1] and patch based workflows in Git itself. Why do we need to wait for, and choose based on, hosted services providing things like that? EDIT: for more clarity; using pull requests and patches with Git itself means that it simple to rebase or whatever, since you're just working with branches and patches directly. Or am I missing something? Other than something like u…

[deleted]

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

#93

Post by e12e »

RVuRnvbM2e wrote: post #24
jbk wrote: 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…

> Especially, it seems to be impossible to add custom searchable fields (like "platforms", "priority" or "modules") which are very very useful to do queries. Also, there is no way to do custom queries and store them ("I want all the bugs for Windows, which are related to the interface modules"). Isn't this use-case covered by Gitlab's issue labels?

I don't know gitlab very well, but I maintained a few trac instances - the thing about trac is that it is (was) an issue-tracker framework rather than a one-size-fits-all out-of-the-box solution. Have a look at:

http://trac.edgewall.org/wiki/TracReports

http://trac.edgewall.org/wiki/TracQuery

http://trac.edgewall.org/ticket/1735

Add in:

http://trac.edgewall.org/wiki/TracTicketsCustomFields

And there's a lot of things available before adding custom plugins.

I'd be interested to hear what limits vlc hit in trac (and why they'd rather move than improve trac. Nothing wrong with that - but I confess I have a soft spot for trac and the team's ethos of "try it as a plugin before making it a core feature").

Also curious if anyone know what, if anything happened with the Apache Bloodhound fork/distribution?

http://bloodhound.apache.org/

I always hoped it held the promise of being a simple to install, opinionated trac for multiple (lean?) projects. But as far as I can tell it was pretty much abandoned.

While part of it might be rails-angst and fear of precious stones - I always felt gitlab was a bit of a heavy hammer in terms of install/dependencies/cloc for "just" project management.

In practice the bundled distribution alleviates that - but I still feel taking the "best of trac" and writing a new system a little more opinionated (and probably with a clearer data model) would be worthwhile. Just another project on the todo-heap :)

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

#94

Post by quesera »

xena wrote: post #84
bovermyer wrote: post #50

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.

> Go is easier to deploy than Rubby on Fails.

You could have said that without cheapening the level of discourse.

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

#95

Post by techdragon »

jbk wrote: 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.

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

#96

Post by rlpb »

jbk wrote: 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…

> we'd love to allow external people to fork our repos

I wonder if this could be solved by making it really easy to fork your repos, but when that happens the fork ends up (with tight integration) back on the/a public GitLab instance.

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

#97

Post by mdk754 »

jazoom wrote: post #60
sqldba wrote: post #45

Because the thread has turned into a "why I like/dislike GitLab over GitHub", I'll say one thing that keeps sending me back to GitHub is the neat-o desktop client. I use a command line for everything else in life; but with Git I'm hopeless.

The GutHub GUI (GutHub Desktop) is pretty bad. Try GitKraken or Sourcetree. You can even use GitHub Desktop with Gitlab if you really want.

I currently do this for the basics, and drop down to git at the shell for anything more complex than the one or two things GitHub's client does well. It's a decent trade off in my opinion.

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

#98

Post by DouweM »

drewcrawford wrote: post #86
DouweM wrote: post #63

Earlier quoted context omitted.

> 1. My hosting is way more reliable than yours :-) You've got me there :) I'm sure your aware of our intention to greatly improve GitLab.com reliability and performance in Q1 2016: https://gitlab.com/gitlab-com/operations/issues > 4. My repository mirroring is quite a lot better than yours, as it's instant, not hourly Heh, care to share? :) Maybe we can take some pointers from your implementation. How does your repo…

> Do you use webhooks on GitHub? That would actually be pretty easy to implement, Bingo. Full implementation, in Bash: http://faq.sealedabstract.com/gitlab_mirror/ > What are you afraid of? Mostly, that you'll get bought by the likes of Oracle. In spite of my quibbles about CE features, I think you're doing a (mostly) fine job of CE right now. But your acquirer will see CE as a cost center (there's no revenue) and wi…

All right, I see where you're coming from. I think any eventual GitLab acquirer would be mad to screw up _our_ winning open core formula, but I'm not in a position to tell the future or make any promises.

I've asked our CEO Sid (you know, the "GitLab CEO here" guy) to chime in.

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

#99

Post by VeilEm »

aaviran wrote: post #87
_yy wrote: 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.

> I understand that Phabricator is a more "complete" solution, but how do they compare in the core features that they both share?

I think GitHub is prettier, but having tasks separate from repos and having tasks be as sophisticated as they are in Phabricator and having such a better pull requests system, it doesn't matter? GitHub has to dumb down the user interface on their product to appeal to the least common denominator and maintain their growth. Phabricator is for projects where people care enough about their projects to learn the UI so they can get things done.

> Also, do they pride themselves for writing this in PHP?

As a user I doubt you're going to find your self caring about how it's written.

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

#100

Post by e12e »

infocollector wrote: post #92

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

Gitlab might have the resources to properly support multiple vcs' - but even though I personally prefer mercurial (ui, reasonable large-file support) - I'm not sure it would be a good idea. Trac (trac.edgewall.org) did a lot of feature-experimentation -- and I think one take-away is that being an effective workflow support tool and supporting (even subtly) different back-ends with accompanying different best-practices/patterns (eg: git sub modules) is hard.

I'd be happy to be proven wrong.

Post reply on HN