Live data from Hacker News

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

41–50 of 325 posts

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

#41
post #30

Earlier quoted context omitted.

> 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 think so. Labels are too limited. We want for every bug, that a few custom fields are always defined, to do a partition of the bugs, and to be able to query on those. Moreover, to change the priority or the platform, it's quite complex to do and will break often. Many bugs won't have it filled, for example. Labels do not guarantee that consistency. As you can see, it's already what people want in the github o…

Just curious, what options would be there for a platform filed? What I'm aiming at are issues that are present on all mobile platforms, all desktop platforms, all x86, ... etc. Either you'd have another dozen of cross-categories or you'd have to use something like check-boxes, which are essentially labels.

Maybe having some set of mandatory labels? I.e. at least one label from platform list, at least one label from priority list, etc...

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

#42

I still don't know how I feel about GitLab. My initial reaction was that they were an underhanded, cheap knockoff of GitHub. It felt kind of dirty, like they were stealing GitHub's thunder and giving it away for free. Then they started charging for enterprise features and turned it into a business, which felt even weirder. And then they raised a lot of money, which kind of made them seem more legitimate. And now this…

We are dealing with a lot of sensitive data and code which is legally not allowed to physically leave our group and GitLab is in my opinion the best open source choice for that. I feel its community edition is up to par with github in most aspects and it a was a change towards the better from our previous svn based solution (Redmine)

There's also Stash (now renamed to BitBucket Server (edit: fixed name, as pointed out in the reply)). It does not include some of the features (such as issue tracking), and I think rightly so. I haven't used GitLab for maybe 2 years now, so I can't compare the two.

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

#43

I still don't know how I feel about GitLab. My initial reaction was that they were an underhanded, cheap knockoff of GitHub. It felt kind of dirty, like they were stealing GitHub's thunder and giving it away for free. Then they started charging for enterprise features and turned it into a business, which felt even weirder. And then they raised a lot of money, which kind of made them seem more legitimate. And now this…

I think you are right about how GitLab started. There is, and there should be, a lot of frustration about the biggest open source hub (GitHub) not being open-source themselves. This feels backwards and creates a harsh dictatorship that shouldn't be. GitLab tried to solve that by making an open source version and because it now can be improved upon by everybody new features start to appear. I love the self hosted aspe…

As a hobbyist I only commit one small thing a week or so without any issues. I'm curious what stability issues they have for later projects, if you'd care to elucidate?

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

#44
post #36

The "crippled community edition vs paid enterprise edition" business model raises red flags. It's not that different from the free crippled demo version or outdated by 2+ major versions freeware model. Who gets to decide that features are enterprise only ? How are these enterprise only features: "Hosting static pages straight from GitLab", "git-annex", "git hooks", etc. ? Get a crippled version that doesn't fit the r…

GitLab CE is not crippled in any way, it is used every single day by hundreds of thousands of companies and millions upon millions of developers. It is and has always been our (GitLab, the company) main focus, we only decide to make new features EE-only when we think that they are mostly interesting to companies with 100+ employees. Besides the company's efforts, contributions from the 1000+ community contributors al…

Just yesterday I ended up implementing my own mirroring of GitHub repositories. GitLab supports this in EE (new in 8.3), but not CE.

That's not a feature that only large enterprises use–I run an open source GitHub organization and wanted to use GitLab as CI. It works! But I needed to reimplement an EE feature to do it.

To be clear, I don't think there is anything sinister about keeping features behind a paid firewall. That is how software developers have paid their rent for decades. I'm just saying that the EE features are not all "mostly interesting to companies with 100+ employees." Several of them are things I needed as a single open-source developer.

I've debated about buying EE to fill in the gaps, but you sell licenses in packs of 10, and I only need 2 :-)

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

#46
post #36

Earlier quoted context omitted.

GitLab CE is not crippled in any way, it is used every single day by hundreds of thousands of companies and millions upon millions of developers. It is and has always been our (GitLab, the company) main focus, we only decide to make new features EE-only when we think that they are mostly interesting to companies with 100+ employees. Besides the company's efforts, contributions from the 1000+ community contributors al…

Just yesterday I ended up implementing my own mirroring of GitHub repositories. GitLab supports this in EE (new in 8.3), but not CE. That's not a feature that only large enterprises use–I run an open source GitHub organization and wanted to use GitLab as CI. It works! But I needed to reimplement an EE feature to do it. To be clear, I don't think there is anything sinister about keeping features behind a paid firewall…

> I run an open source GitHub organization and wanted to use GitLab as CI. It works! But I needed to reimplement an EE feature to do it.

Is there a reason why you didn't use GitLab.com, which runs EE and thus has Repository Mirroring?

> I'm just saying that the EE features are not all "mostly interesting to companies with 100+ employees." Several of them are things I needed as a single open-source developer.

Fair enough, I'm not saying our judgment of what is and what isn't interesting to smaller/single-person teams is perfect. If the general feedback of the community is that a certain piece of functionality belongs in CE rather than EE, we will consider bringing it to CE. We have done this in the past.

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

#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 wanting to host a new project could just fork yours, then make a a commit that deletes everything currently in there, then start their new project.

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

#48
post #42

Earlier quoted context omitted.

We are dealing with a lot of sensitive data and code which is legally not allowed to physically leave our group and GitLab is in my opinion the best open source choice for that. I feel its community edition is up to par with github in most aspects and it a was a change towards the better from our previous svn based solution (Redmine)

There's also Stash (now renamed to BitBucket Server (edit: fixed name, as pointed out in the reply)). It does not include some of the features (such as issue tracking), and I think rightly so. I haven't used GitLab for maybe 2 years now, so I can't compare the two.

It's named bitbucket server or something like that - don't confuse it with bitbucket proper.

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

#50
post #28

Earlier quoted context omitted.

We are dealing with a lot of sensitive data and code which is legally not allowed to physically leave our group and GitLab is in my opinion the best open source choice for that. I feel its community edition is up to par with github in most aspects and it a was a change towards the better from our previous svn based solution (Redmine)

A good friend of mine likes to run https://gogs.io/ .. I havent used it heavily but Ive been impressed so far.

I was unaware of this. Thanks for the link.

It seems just about everything is being re-written in Go these days...

Post reply on HN