8 ms·

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 librarie

by jbk 11y ago

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

RVuRnvbM2e 11y ago
> 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?
- jbk 11y ago
  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 open letter.
  - rplnt 11y ago
    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...
- technomancy 11y ago
  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.
  - masklinn 11y ago
    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] [0] https://github.com/rust-lang/rust/labels https://github.com/rust-lang/rust/labels [1] https://github.com/rust-lang/rust/issues/5016 https://github.com/rust-lang/rust/issues/5016
    - unethical_ban 11y ago
      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.
- e12e 11y ago
  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/TracReports http://trac.edgewall.org/wiki/TracQuery http://trac.edgewall.org/wiki/TracQuery http://trac.edgewall.org/ticket/1735 http://trac.edgewall.org/ticket/1735 Add in: http://trac.edgewall.org/wiki/TracTicketsCustomFields 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/ 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 :)
lmm 11y ago
> 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.
- 131hn 11y ago
  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)
  - lmm 11y ago
    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?
    - 131hn 11y ago
      I'll say it is legit to be hosted on gitlab.videolan.org (edit typo)
- e12e 11y ago
  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).
- jbk 11y ago
  > On a technical level that seems an impossible distinction to make. Sure, but at least it would be clear what is 'allowed'.
techdragon 11y ago
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.
- jbk 11y ago
  Yes, we did. Unfortunately, it's not really easy to help people fork the repos.
- ausjke 11y ago
  Phabricator has so many "strange" naming and after some basic reading I never found it's interesting/easy enough for me to get started, sigh. redmine, gitlab, bitbucket, github are what I am using for various things.
rlpb 11y ago
> 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.
sytse 11y ago
We would love to help you to host VideoLAN on a on-premises GitLab instance. Thanks for raising the issues you did. 1. Our EE version has the function share project with other groups http://doc.gitlab.com/ee/workflow/share_projects_with_other_groups.html http://doc.gitlab.com/ee/workflow/share_projects_with_other_... If this is essential for you we'll give you a free lifetime license for GitLab EE. 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 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#improvements 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.html 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.
- thresh 11y ago
  [videolan infra guy here] 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.
  - Afforess 11y ago
    Gitlab EE is actually open source. https://gitlab.com/gitlab-org/gitlab-ee https://gitlab.com/gitlab-org/gitlab-ee
treenyc 11y ago
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
aerovistae 11y ago
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.

by jbk 11y ago

RVuRnvbM2e 11y ago

> 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?

jbk 11y ago
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 open letter.
- rplnt 11y ago
  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...
technomancy 11y ago
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.
- masklinn 11y ago
  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] [0] https://github.com/rust-lang/rust/labels https://github.com/rust-lang/rust/labels [1] https://github.com/rust-lang/rust/issues/5016 https://github.com/rust-lang/rust/issues/5016
  - unethical_ban 11y ago
    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.
e12e 11y ago
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/TracReports http://trac.edgewall.org/wiki/TracQuery http://trac.edgewall.org/wiki/TracQuery http://trac.edgewall.org/ticket/1735 http://trac.edgewall.org/ticket/1735 Add in: http://trac.edgewall.org/wiki/TracTicketsCustomFields 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/ 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 :)

lmm 11y ago

> 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.

131hn 11y ago
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)
- lmm 11y ago
  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?
  - 131hn 11y ago
    I'll say it is legit to be hosted on gitlab.videolan.org (edit typo)
e12e 11y ago
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).
jbk 11y ago
> On a technical level that seems an impossible distinction to make. Sure, but at least it would be clear what is 'allowed'.

techdragon 11y ago

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.

jbk 11y ago
Yes, we did. Unfortunately, it's not really easy to help people fork the repos.
ausjke 11y ago
Phabricator has so many "strange" naming and after some basic reading I never found it's interesting/easy enough for me to get started, sigh. redmine, gitlab, bitbucket, github are what I am using for various things.

rlpb 11y ago

> 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.

sytse 11y ago

We would love to help you to host VideoLAN on a on-premises GitLab instance. Thanks for raising the issues you did. 1. Our EE version has the function share project with other groups http://doc.gitlab.com/ee/workflow/share_projects_with_other_groups.html http://doc.gitlab.com/ee/workflow/share_projects_with_other_... If this is essential for you we'll give you a free lifetime license for GitLab EE. 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 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#improvements 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.html 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.

thresh 11y ago
[videolan infra guy here] 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.
- Afforess 11y ago
  Gitlab EE is actually open source. https://gitlab.com/gitlab-org/gitlab-ee https://gitlab.com/gitlab-org/gitlab-ee

treenyc 11y ago

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

aerovistae 11y ago

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.