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 the change.
The first part is the groups and subgroups: it seems incredibly difficult to give sub-groups access to repos (like a team for iOS, one for Android, one for libVLC... but all are under the "videolan/" group). It seems there is a way with the EE, but not in the CE; and the current idea for the CE is to have sub-projects, which is not good, because it will make our URLs way more complex than needed.
The second part is the bugtracker/issues tracker. We use trac for VLC, and we want to leave it for something better; but gitlab issues is way too limited, even when using the templates. 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").
If I remember correctly, this second part was also a complaint in the open letter to github.
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.
PS: can we have custom landing pages and custom logo in the CE version? :D :D
2. You can add custom labels on issues and the searches can be stored in urls that you can bookmark and use in links. You might have considered this already and need more functionality. Maybe it is best to discuss this in an issue so I created https://gitlab.com/gitlab-org/gitlab-ce/issues/10712 Please add there what you need in addition to the labels functionality. We addressed the long list of items raised in the original Google Doc letter below the signatures in https://gitlab.com/gitlab-org/gitlab-ce/issues/8938#improvem... The first item under improvements details our reponse to that question.
3. In GitLab you can give each user a fixed number of new projects. That should prevent people from storing a excessive amount of repo's. But feel free to make a feature request to limit people to only forks. As other replies have indicated that still allows people to work around it but at least the intention will be clear.
4. A custom landing page and logo is an EE feature http://doc.gitlab.com/ee/customization/branded_login_page.ht... We think this is more relevant for larger organizations so we're comfortable for having it as EE only at the moment. As mentioned under 1. we're open to offering you (and other open source projects considering self-hosting) a lifetime EE license.
I'll be in the comments today (just woke up in SF). You and any other open source project can always reach me at sytse@ company domain to get assistance or claim the EE license.
The whole idea of VideoLAN infrastructure migration from gitweb/trac/etc to gitlab and not to github was to use and promote free and open-source software.
Using closed-source software there is out of question, really.
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.
My understanding from taking a Red Hat sysadmin course is that what you get from a RHEL subscription is firstly access to their repos from which to download updates and additional packages. The other, perhaps bigger, portion of a RHEL subscription is the support; I think they will answer the phone and provide you fixes for any bugs in RHEL-provided software relatively quickly. This is nice for companies, for whom uptime and stability are often superior to most other concerns, like staying close in feature parity to upstream.
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.
"This software and associated documentation files (the "Software") may only be
used if you (and any entity that you represent) have agreed to, and are in
compliance with, the GitLab Subscription Terms of Service, available at
https://about.gitlab.com/terms/#subscription (the “EE Terms”), and otherwise
have a valid GitLab Enterprise Edition subscription for the correct number of
user seats."
Thanks a lot for the answer and the proposal. But we do not want to have anything critical that is not open source. We try to promote OpenSource, so using non-open-source software is hard to do.
1. Thanks, but see above :)
2. As I said, custom labels are way too limited, as people on the open-letter-to-github said, so I will comment on the issue.
Thanks, I get that you don't want to be on proprietary code. I'm look forward to your email. And we're open to discussing open sourcing features if that is needed.
I don't know if that would apply to GitLab too, but maybe consider switching from the CE / EE model to just one "product" and a free for non-commercial model? Like e.g. http://3t.io/mongochef/download/ does it? I like that model way more than a feature-reduced version.
We considered that but we value having a completely open source version for all projects more. For more information about how we see the difference between CE and EE please see https://about.gitlab.com/about/#stewardship
What about having a single product, and charging for a proprietary license + support? This may work better with GPL as many large orgs are allergic to it.
With MIT license, many sites probably just implement the branding changes etc in the CE product on their own.
We want to give large orgs the option to run GitLab without having to pay us. We don't mind having people add features to CE, these are the same people that will send enahancements upstream and make GitLab better for everyone.
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.
Instead of offering a free EE license I think the better thing to do is to open source features in EE that are deemed essential. So if you run a significant open source project and are considering switching to self hosted GitLab please let us know what EE features are blocking you (if any). This will allow us to open source them.
systse, I have nothing of value to add to this topic but as usual I want to thank you guys for the work you do. Gitlab may not be perfect but it's heartwarming to see an awesome open source project being supported like this and it's always really nice to see companies thrive on FOSS-first models.
Well, I can understand that having a business model which actually is stable and makes around FLOSS is hard, so I can tolerate a lot of wiggling around the edges of freedom. However, what I cannot tolerate is freedom of my data. Our IT guys are uneasy to installing supported version of GitLab internally (aside from the small question of money), because they are afraid that once we install EE version, we are locked into it. Is there a supported way how to get from EE to the true opensource version of GitLab and not to loose any data (aside from functionality not available in CE)?
I'm still considering what to do with git.xiph.org and trac.xiph.org, and gitlab is one of the options. One thing I know for sure, just as with Videolan, a proprietary licensed solution like the EE is out of the question.
> 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 care about.
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.
> 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.
Yet, there is still differences. Allowing only "fork" is a good and easy thing.
Having a fork that delete everything and start a new projet is easy to detect and label as spam. (there will always be abuses, but it's okay as long as you can mitigate/moderate)
I'd think it's pretty easy to have a policy that says "only VLC forks or VLC-related projects". What if someone wants to pull out part of VLC into its own library?
On your own instance, disallow creation or restrict of further projects. Ask people to use the 'Import any repo by URL' feature in GitLab on their own instance / GitLab.com.
We're planning to add cross-server merge requests in the future, which would make it that you don't have to host the forks yourself [0].
It would still send a signal of "please don't do that" - and could be "enforced" with some change/diff tracking in a cron job (all files changed removed - prompt someone to have a look, or just freeze access for a week/month then schedule for deletion).
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.
> 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.
> 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:
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?
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 :)
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 open letter.
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...
If you have to create a label for every platform you support and every existing priority and module, the labels list will become really cluttered, making it hard to find things.
It becomes very long, but it doesn't seem overly cluttered, and it avoids the risk of overly restrictive either/or classification. Rust makes extensive uses of labels on github, they're up to 120 at this point[0] and it seems to work reasonably well even with old issues with a fair number of labels[1]
FWIW, at my office for the small projects we have tracked, we use a similar method.
type-label
Types:
b - bug
f - feature
p - priority
t - team
So we might have issues tagged "p-med b-confirmed t-group1"
Once there is a method to the madness, it's not bad, and it's more flexible on Gitlab's part I'm sure, to have people tag instead of supporting custom drop-down attributes.
Can I just take this moment to say I love VLC; it's one of the best and most reliable programs ever; it does EXACTLY what I want 100% of the time and I am always astounded to discover some neat feature that fits some odd need I have. To you and your team, thank you so much for making it so effortless to watch so many different things without having to worry about formats, codecs, subtitles, audio tracks being off, etc etc etc. Thank you so much.
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 the change.
The first part is the groups and subgroups: it seems incredibly difficult to give sub-groups access to repos (like a team for iOS, one for Android, one for libVLC... but all are under the "videolan/" group). It seems there is a way with the EE, but not in the CE; and the current idea for the CE is to have sub-projects, which is not good, because it will make our URLs way more complex than needed.
The second part is the bugtracker/issues tracker. We use trac for VLC, and we want to leave it for something better; but gitlab issues is way too limited, even when using the templates. 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").
If I remember correctly, this second part was also a complaint in the open letter to github.
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.
PS: can we have custom landing pages and custom logo in the CE version? :D :D