New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open development of Debian package spec #8978
Comments
Hi @trs80, Thanks. I know about these tickets, there is much more of them actually. I just wanted to be more specific. |
Sure, I just wanted to link them for other people coming to the ticket. |
Some time passed, can someone give a word, why packaging stuff for Debian/Ubuntu isn't published? Since whole project is licensed and released as Free software, I'm not sure what reasons are behind not publishing packaging stuff. Releasing it would be really helpful! (and I believe by looking at number of 👍 for this issue I'm not alone). EDIT: If this stay without answer, I plan to try package it for Debian (which will be really sad, doing it from scratch instead of using existing code). |
maybe we will find that the package does not contain the published code ;) |
@okias There is interest in achieving the original aim of this issue but a) time b) efforts on 2.3 right now are on getting it stable. As far as I'm aware, we may only see open sourcing of the packaging in 2.4. |
So I assume that currently distributed @matiasilva |
I'm not involved with the core software, but it's not as easy as you're making it sound. Making anything public, especially on this scale, will lead to volumes of issues, confusions and whatnot when people don't understand how to use the packaging or why it is the way it is. This will detract and take away time from 2.3, which is the current version being developed. There are considerations you and I are not party to, so we can't make any assumptions. And as for the license, from what I've heard, it doesn't mean that the .deb packages have a non-free license, it's just that there hasn't been enough time to get around to it. I would recommend just being patient and understanding of the situation because it is definitely a priority that the core developers are aware of. |
@matiasilva few months passed (about patience). About preventing confusion by hiding things from user/administrator/anyone - well, companies do this kind stuff, but then you cannot call it "open-source", since it's not open. Not even talking about spirit of Free software, collaboration and higher goals. Anyway, when I get some free time, I plan to write debian package for it (silly, right - since they exist). If anyone wants to start, I don't mind thou and I'll happily review and try to help with development. |
The plan was to get the packaging updated and released in 2020, but with Covid-19, all our resources went into updated 2.2 (we released 31 updates in 2020. Work is currently underway in 2.3 to refactor the packaging scripts and build process so they can be published, so if you can hang on a bit, you'll get an official build process for 2.3. |
@ffdixon 2.3 is out, 2.4 beta ongoing. |
Link to the initial pull request including the scripts: #12993 |
I believe these objectives have been reached. BBB 2.5 is built using these open source scripts ^. BBB 2.4 included an initial version of them that saw some improvements and is used by some deployments. The official BBB 2.4 packages were still relyin g on the "closed" packages though. With BBB 2.5 this is also addressed. Please feel free to open new issues with narrower scope if additional info is needed or if tweaks are desired/recommended. |
Is your feature request related to a problem? Please describe.
There’s room for improvement of bigbluebutton packages specs, but they are closed source, development is closed and behind the scene.
Describe the solution you'd like
Please release specs of packages under terms of LGPL, like the rest of the project. So users may contribute improvements to them.
Describe alternatives you've considered
If you don't want to open your specs, then please explicitly state this and allow contributors to develop them from scratch, e.g. accept contributions that will create new specs from scratch.
Additional context
Currently, there is a very high demand on this project, so let's not waste time on doing behind the scene development. Users want to adopt this project for as many environments as possible, and they are willing to contribute and take responsibility of support of such environments.
The text was updated successfully, but these errors were encountered: