LibreTime 3 Beta Todos

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.

1 Like

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.

Cool we should highlight it. I’m assuming it gegets built manually for each release ?

Yup. I build for amd64 Debian and upload the source changes to Launchpad for it to build for amd64 and i386

So does this project board reflect the current priorities? https://github.com/LibreTime/libretime/projects/2

Are these the remaining development issues that need to be claimed and resolved? https://github.com/LibreTime/libretime/projects/2#column-5144349

The rest are documentation? https://github.com/LibreTime/libretime/projects/2#column-5144368

What about issues labeled as bug https://github.com/LibreTime/libretime/issues?q=is%3Aissue+is%3Aopen+label%3Abug

Are some of those potential release blockers?

Per https://github.com/LibreTime/libretime/issues/544#issuecomment-608034378

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.

Thoughts?

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.

With a MVP platform to build on, OpenProducer can finally help facilitate all of the above. This could be a good entry point - https://github.com/OpenProducer/openproducer-platform/issues/18

Probably old news, but I’m just noticing SourceFabric completely dropped support of the free open-source Airtime https://www.sourcefabric.org/en/airtime/

Would be pretty cool if, in the not too distant future, LibreTime could provide a better free and SaaS version for frustrated Airtime users.

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.

1 Like

So there are only 4 unassigned release blockers - https://github.com/LibreTime/libretime/issues?q=is%3Aopen+is%3Aissue+label%3A3.0-release-blocker+no%3Aassignee

Possibly 3 if the issues related to the player are combined -

As @paddatrapper mentioned in https://chat.libretime.org/ the SSL one looks fairly straight forward https://github.com/LibreTime/libretime/issues/88

The remaining unclaimed issues people were suggesting solutions or offering help -


Does that seem like an accurate assessment?

If there are folks interested/able to helping get 3.0 out the door, please don’t be shy about jumping into the issue queue or joining https://chat.libretime.org/libretime/channels/developers

This issue has now been claimed by mepholic!

Down to two unclaimed release blockers as referenced in the previous comment.