So I spent some time going through the beta 3 release blocker issue and I closed a number of issues and unassigned a few others and wrote a PR to fix one of them.
So here is my quick summary of what we need to fix before we finally belatedly declare ourselves a “beta”.
Fix CORS_URL during the web-based install.
Document and setup Lets Encrypt SSL for new installs and resolve Nginx Reverse Proxy issues
Fix the web player & widget so that it works by default on as many browsers by default
Document how to easily upgrade and backup LibreTime
Remove the Facebook Widget (or test and fix it)
Test upgrading from Airtime 2.5
Add a PPA for debian based systems
Merge Python 3 port
Watched Folders upgrade from Airtime 2.5 and/or for new installs
I’d also like us to have a deb based install so people can install and upgrade easily w/o running git. That and/or a docker based install are probably good goals but not necessary.
I also removed porting over the launch page that @ned-kelly had created because we have made no progress on that and so it’s hard to make it a blocker but a more user friendly page would be a good goal before we make an official release.
So I’ll try to assign the issues to myself or whomever is working on it so we can see what else needs to be done and/or needs someone to volunteer.
Do you mean adding the Ubuntu PPA into the installer? PPA’s are Ubuntu specific, so we would need to host our own APT repo for Debian if we wanted to do that. Alternatively, we get LibreTime into Debian, but that will take some work
YeYeah I forgot PPAs were Ubuntu specific bit it’d be good to have the one with the silan fix by default with the installer. A repo with libretime packages would be cool as well for Debian I haven’t checked the status of the deb packaging. How is it going ?
The deb package works, but contains a lot of stuff that needs working out before it would be able to get into Debian. Those are pretty much stalled and I think waiting for potentially an API and front-end rewrite would be useful so that we can get away from having to package a ton of old/outdated dependencies and can focus on using current software that is already packaged for Debian. So picking JS, Python, etc libraries that are already packaged and target versions that are in Debian or newer.
If one person (ideally not one of the core maintainers) could assume the PM/scrum master role, possibly we could coordinate some virtual sprints with the goal of 3.0.
Yeah. Those need to get done for 3.0 to be released
The ones that are should be labelled with ‘3.0-release-blocker’. Please let us know of any that you think are release-blockers that are not labelled as such
Shouldn’t the next major release be bug free? Would it make sense for @robbt to run point on this and assign or tag priority tasks w/ help wanted (or something like that)?
I’d like to help coordinate an effort to direct financial resources towards the 3.0 and other priorities referenced in this post.
No software is ever bug free, especially one as complex as LibreTime. There are just bugs we don’t know about, even fixing the ones we know about will require a lot more time than we currently have. The issue is a lack of development hours to dedicate to the project as much as anything else. The original Airtime was developed with many high $ amount grants to SourceFabric and a team of multiple full-time developers. We are keeping it alive as best we can. I plan on continuing to dedicate as much hours as I can towards it.
Anyways, getting to “beta” is our goal at this moment. Getting new developers in will happen as they show up. If we wanted to “meet” in real time more often to discuss priorities that might help but I don’t know that there are a lot of untapped resources/developers just waiting to join in.
As referenced in my previous comment, funds to help devs spend more time to get 3.0 beta out the door will most likely come indirectly from services, a paid beta, or hackathons.
I personally don’t think SaaS is the way to go. I would prefer to offer support for running LibreTime on end-users own hardware and software and provide installation expertise etc. versus getting into the hosting game directly. In addition if anyone where to offer SaaS they would be bound by the Affero GPL v3 to release all of their code thus making it easy for anyone else to copy their setup so there is no real incentive here other than providing mark-up on rented cloud servers. I suspect that Airtime.pro has never been a big source of profit for SourceFabric and I am pretty sure they developed Airtime primarily with grant money they received from various NGOs etc to develop open-source radio software. I suspect that this might be the best route for LibreTime as well.
LibreTime is being used by more and more broadcasters and web streamers. Especially by those that value their freedom and autonomy from cloud services and SaaS platforms that can exert control over their users and create external dependencies. I’d like to make it so that LibreTime has a robust enough setup that people can easily install it on their own and don’t need to pay us to host it. I think that the business model NextCloud has followed is aspire to. I am always suspicious when a business model relies upon a freemium version with a paid version because there is a temptation to water down or limit functionality artificially on the freemium version. This is the issue the founder of NextCloud ran into when he founded OwnCloud and received a bunch of investments. There was a conflict between the community and the company because of this. See this talk at LibrePlanet 2019 that influenced my thinking here - https://media.libreplanet.org/u/libreplanet/m/why-i-forked-my-own-project-and-my-own-company-31c3/.
Anyways thanks for moving the conversation forward, going to go back to working on release blockers for v3.
Seems like one of the main goals/challenges coming out of yesterday’s online meeting was the usual “how do we get a 3.0 out the door?”.
If the release blocker board is accurate it seems like there are just a few blockers on the todo list and a few more in progress. Out of those, just a couple unclaimed.
Would be good to know if folks on working release blockers need help.
I can take care of these two tasks (document SSL and replace the player), I’ve been recently messing around with icecast and libretime for configuring SSL, so I have it pretty fresh. And regarding the player, I have been thinking since a while about changing it to https://jplayer.org, I don’t know what you think about it.
The SSL documentation is already there - LibreTime - SSL Configuration, but probably needs some more visibility under the For System Administrators at the bottom of the docs page.
@xabispacebiker Are you talking about the issue below? If yes, it looks like there’s been some progress. Might be good to chime in and ask for a status update.