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

Almost Everything We Do Will Be Open

about.gitlab.com

Post reply on HN
Print view View original

131–140 of 208 posts

Re: Almost Everything We Do Will Be Open

#131

Post by hk__2 »

scrollaway wrote: post #62
jobvandervoort wrote: post #15

Earlier quoted context omitted.

That's great to hear. You can give it a try / use it for free at GitLab.com (public and private). We would love to hear what hardcore GitHub fans like you miss in GitLab. We want to be better.

I'm not sure you can fix it unfortunately but the number 1 thing I would miss is the community . I work with a lot of open source projects and the consistency and speed at which I can file bugs, fork repositories and pretty much do anything is really important, and the access to all the github users is a major part of that. -- OK, this post was going to be some minor thoughts but turned into actual UX/dev feedback. T…

> SSL support for gh-pages on custom domains is lacking

How could they do that? You’re responsible for your own domain, you have to buy an SSL certificate by yourself.

Re: Almost Everything We Do Will Be Open

#132

Post by hk__2 »

r0naa wrote: post #86

I am moving my stuff to a self-hosted GitLab. If you are interested in knowing why: - I personally find it a little bit irritating that Github wants to promote "open-source/free-software", but haven't open sourced their own tools/product. - I was disappointed by the way Github handled some internal problems - I don't trust Github anymore; I want to be in control of my data.

> I personally find it a little bit irritating that Github wants to promote "open-source/free-software", but haven't open sourced their own tools/product.

They have 100+ open-source repos: https://github.com/github They also contribute a lot back to Git.

Re: Almost Everything We Do Will Be Open

#133

Post by pbiggar »

kanzure wrote: post #130
pbiggar wrote: post #127

Earlier quoted context omitted.

Question for you: as a GitLab Enterprise user, knwoing that GitLab has CI built-in, is there a situation in which you would buy CircleCI to go alongside it? Obviously we (we being CircleCI, founder here) have GitHub Enterprise support, and I wonder if we should build GitLab Enterprise support too.

> is there a situation in which you would buy CircleCI to go alongside it? Well, we were using circleci for a while until the switch to gitlab-ci just recently. Biggest problem was that the circleci runners lose the local docker cache, which meant that unnecessary large chunks of time were spent redoing docker container builds, slowing everything down in our workflow. Note that we run unit tests in docker containers,…

Yeah, fixing that is a very high priority for us atm.

So assuming we fixed that, would you buy it (considering esp that GitLab CI exists and you already use GitLab)?

Re: Almost Everything We Do Will Be Open

#134

Post by kanzure »

pbiggar wrote: post #133
kanzure wrote: post #130

Earlier quoted context omitted.

> is there a situation in which you would buy CircleCI to go alongside it? Well, we were using circleci for a while until the switch to gitlab-ci just recently. Biggest problem was that the circleci runners lose the local docker cache, which meant that unnecessary large chunks of time were spent redoing docker container builds, slowing everything down in our workflow. Note that we run unit tests in docker containers,…

Yeah, fixing that is a very high priority for us atm. So assuming we fixed that, would you buy it (considering esp that GitLab CI exists and you already use GitLab)?

> So assuming we fixed that, would you buy it (considering esp that GitLab CI exists and you already use GitLab)?

Yes but no, we already switched and we're on to other things. We reported the docker cache issues to you guys a looong time ago, and we get it- most of your customers are probably focusing on webapp unit testing, and probably not on building docker containers and then running unit tests in those containers. There's a lot of hammering to get each CI solution to work just right, but maybe we could switch back more easily if you guys made a gitlab-ci compatibility layer..... (big project, I know).

Oh also we have somewhat-malleable self-hosting requirements, but I mean for the right solution we've been able to forego self-hosting in the past.

Re: Almost Everything We Do Will Be Open

#135

Post by sytse »

kanzure wrote: post #123
skyraider wrote: post #121

Earlier quoted context omitted.

> I don't know what you mean exactly. Do you mean you want to test the code that will result after the merge instead of the commit in the feature branch? It would be a nice option to test the merge of the feature branch with master instead of the feature branch itself (you will have to retest all MR’s every time master is updated). BTW The new build trigger API (to be released in a month) is one of the upcoming featu…

> But I do want to run integration tests before that feature branch gets merged upstream. Specifically, the integration tests should run against the version of the source code in the feature branch that the merge request is about. The target branch can be merged into the feature branch to have full coverage of the post-merge status, so the target branch's importance is really minimal here. > Yes, it would be a nice o…

Yes, it would be a nice option to test the merge of the feature branch with master instead of the feature branch itself (you will have to retest all MR’s every time master is updated).

Re: Almost Everything We Do Will Be Open

#136

Post by nadams »

antsar wrote: post #125
nadams wrote: post #116

Earlier quoted context omitted.

It doesn't matter which product it was for - it still seems contradictory. It says I can distribute patches but then it says I can't. I wasn't joking when telling you that you should get a lawyer on the phone. I've seen a number of people try to write their own software license - and fail miserably. It really has me kind of worried that your response wasn't "we did consult with a lawyer when creating that license".

In what way does it seem contradictory? It seems to allow one to write and publish patches , while disallowing the redistribution/resale of the original code .

Distributing a patch would require distributing parts of the original code (the patch file will include lines of original and changed code) - which the latter is not allowed per the license.

I'm not saying that gitlab would go after you for just distributing a patch - but if anyone gobbled up gitlab coughOraclecough I'm sure they would summon a swarm of lawyers at your doorstep.

Re: Almost Everything We Do Will Be Open

#137

Post by sytse »

lgp171188 wrote: post #112
jobvandervoort wrote: post #2

As always, if anyone has any questions, we're here.

Would appreciate better support for the Integration-Manager workflow described in http://git-scm.com/book/be/v2/Distributed-Git-Distributed-Wo... . It is possible to use this workflow with Bitbucket and GitHub but not with GitLab (possibly due to the differences in roles and permissions). I had already raised a feature request for this some time back. Would appreciate your thoughts on this.

Can you maybe link to the feature request?

Re: Almost Everything We Do Will Be Open

#138

Post by ZenoArrow »

robotresearcher wrote: post #107
ZenoArrow wrote: post #85

Earlier quoted context omitted.

Isn't there a slight problem with having the EE code publicly viewable? What I mean by this is, what's stopping someone from taking code from the EE, modifying it, and including it in the CE? On the flip side, what if a feature released to CE is too similar to code in EE, even if the author of the patch never read the EE code for inspiration? Would GitLab be within their rights to stop it? With these issues in mind,…

> what's stopping someone from taking code from the EE, modifying it, and including it in the CE? 1. Copyright law. 2. For corporations it's probably more cost effective to pay a subscription than maintain a fork.

1. It's not necessarily easy to prove that the new code has its origin in the existing code.

2. For some corporations, yes, for potential competitors, no. Furthermore, I wasn't talking about a fork, I was talking about committing to CE.

Re: Almost Everything We Do Will Be Open

#139

Post by sytse »

drinchev wrote: post #71
jobvandervoort wrote: post #36

Earlier quoted context omitted.

We do not make substantial money with GitLab.com. It gives us the possibility to run GitLab on a very large scale. This helps us finding performance and scaling issues that otherwise would go unseen. In short, it allows us to make GitLab even better.

If this is really the case and your business model is aligned with this, there's nothing else to say, except "Congratulations!". I didn't know that this can go so well for end-users in such a competitive environment. I hope I hear more arguments like these from other tech companies. How do you call this model? I guess freemium doesn't match with how you make the benefit out of the website.

I guess it is freemium because most larger organizations at some point want to go on-premises (for security, legal, flexibility or other reasons) and opt for GitLab EE at that point.

Re: Almost Everything We Do Will Be Open

#140

Post by sytse »

btashton wrote: post #98

I set up gitlab internally a couple years ago and it has been a pleasure. One big thing I fight is we have a lot of micro services that we want to have the same label set for and would like to manage against the same milestones. It would be really nice if label sets and milestones could be created for a group.

Feel free to contribute that feature. I would love to create a milestone for all projects in a group in one go. Please be aware that if you name the project milestones the same you can use them to aggregate issues across multiple project in one view.
Post reply on HN