Earlier quoted context omitted.
wm in wm_web refers to "wordmark" - looks like it's not displaying correctly in your browser! which one?
Safari 9
BTW, this was fixed! https://gitlab.com/gitlab-com/www-gitlab-com/issues/513
Dear open-source maintainers, a letter from GitLab
281–290 of 325 posts
Re: Dear open-source maintainers, a letter from GitLab
#282Earlier quoted context omitted.
Gitlab EE is actually open source. https://gitlab.com/gitlab-org/gitlab-ee
If you need help on the difference between "publicly viewable" and "open source" see this answer to a related question on the Open Source Stack Exchange: http://opensource.stackexchange.com/questions/2338/can-i-use...
Note that the accepted answer there is wrong, as it ignores the fact that the question asker wanted to distribute virtual machines containing the software, which is a violation of the GPL. The currently second answer by h22 is correct.
Re: Dear open-source maintainers, a letter from GitLab
#283Any chance you can support Mercurial? There was a highly voted issue that I saw sometime back.
We'll not support Mercurial, this would be an additional layer of indirection and limit us to features that are supported in both Git and Mercurial.
There's no real limitations on making the two VC system compatible, that's why RhodeCode has same functionality for both Git and Mercurial, without making tradeoffs, that's why systems like hg-git could also work out quite well.
Re: Dear open-source maintainers, a letter from GitLab
#284Earlier quoted context omitted.
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.
Is Rhodecode completely open source like Kallithea?
No, Kallithea is an fork of older code base of RhodeCode.
RhodeCode source code is not open, but it's free up to 25 users
There's a big difference between Kallithea and RhodeCode. Kallithea development is stale, and there's not a lot of things going on in this project.
RhodeCode is adding new features constantly, and the project is really active.
Re: Dear open-source maintainers, a letter from GitLab
#285Earlier quoted context omitted.
The opportunity cost on the front side is often worth it but the long term benefit on the back side is you aren't dependent on that SaaS, are running stuff you know something about and have a lot of flexibility. I'm from the old school, I use SaaS/PaaS mostly for stuff I know is painful to do yourself (sometimes file storage, nearly always email) but the rest lives on vanilla boxes configured with ansible (frankly an…
Can you suggest a good way to get started with Ansible?
The ansible docs are excellent and walk you through the process, one thing I did (and would suggest) is use vagrant (or similar) with ansible, it has built in support for it and it allows you build/tear-down way faster while you are learning.
Re: Dear open-source maintainers, a letter from GitLab
#286With 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…
Another one we found easy to use is GitBucket that has most of github
If you have Java
just type download gitbucket.war
> java -jar gitbucket.war
Re: Dear open-source maintainers, a letter from GitLab
#287Earlier quoted context omitted.
Have you ever considered using the AGPLv3 for the Community Edition, rather than the all-permissive MIT license?
I'm pretty sure they take outside contributions for CE, so if that was AGPL3 they wouldn't be able to use it in Gitlab EE, which sounds like shooting themselves in the foot.
They could require a CLA for outside contributions. Many organizations do that.
Re: Dear open-source maintainers, a letter from GitLab
#288What I would like to have in the free version is:
- Project importing from Stash to GitLab
- Mirror Projects
- Display merge request status for builds on Jenkins CI
- Rebase merge requests before merge
- Git hooks (commit message must mention an issue, no tag deletion, etc.)
These are pretty essential.
Re: Dear open-source maintainers, a letter from GitLab
#289Earlier quoted context omitted.
> If this is essential for you we'll give you a free lifetime license for GitLab EE. While I get the sentiment, I don't think this helps. If you want to help the Open Source community, give us what we need in the form of open source. If I don't care about vendor lock-in I can go ahead and use GitHub. GitLab counts because its open source, and its open source version is the only thing the open source community should…
That makes sense and we want to make sure GitLab CE is a great solution for open source projects. If there is an EE feature that is would come up frequently in these conversations we would not hesitate to open source it.
this is probably not the right forum to express this on, but it's what's in front of me right now and it's topical, so here it goes:
I have seen the feature of being able to customize the login screen come up in discussions about gitlab come up so many times, in so many places, and I usually see it met with "EE feature" or a community member saying something like "gitlab is open source just change the files on your server".
This seems like such a basic thing for an open source software like gitlab to just provide out of the box, i can't believe it isn't listed under your " ... an EE feature that is would come up frequently in these conversations ... " that you "would not hesitate to open source". Especially since at least several of the people you're replying to in this thread have mentioned it specifically.
Is gitlab really making enough income from enterprises who decide that this is the killer feature that they need to pay for EE to get?
It seems like a simple matter of moving the gitlab branding on the login page to the footer with a "powered by gitlab" type of thing and a logo.
Please don't take my meaning as a hateful rant, I love gitlab and personally manage 2 seperate deployments of gitlab CE, but i am not ashamed of saying that this is something of a frusteration to me, and I have a hard time taking this
>If there is an EE feature that is would come up frequently in these conversations we would not hesitate to open source it
statement seriously in light of how many times I have seen this seemingly harmless feature shot down for essentially no real reason.
Re: Dear open-source maintainers, a letter from GitLab
#290Earlier quoted context omitted.
The GitLab EE source is publicly viewable, but its license is not open source. See https://about.gitlab.com/2015/05/22/gitlab-7-11-released/ .
This is really a problem I think. Maybe GitLab could reconsider to adopt a licensing model[1] for the Enterprise Edition that would make it more Free Software friendly? [1] I.e. a licensing model based on GPL and selling services that Red Hat uses for RHEL, instead of a licensing model like they, and a minority of the "open source" companies, use.
When we introduced the Enterprise Edition we had it under MIT license. This caused much confusion with our customers. Maybe the situation is better now with companies like Hortonworks educating the market. But unlike others we want to make our open source edition as simple to install and maintain as the paid version.
Anyway, maybe you could be a bit more specific about the problem you see with our model, I would love to get specific. Also see https://about.gitlab.com/about/#stewardship
BTW I presume RedHat choose a GPL license for RHEL because they didn't have a choice due to the GPL license on Linux.