Libretime: Proposal: Define our goals and roadblocks to release a 3.0 beta

[Robbt]

Basically there has been discussion at various place about when we can transition LibreTime from alpha to beta. I think that we need to explicitly call out any show stopper bugs or missing functionality that would prevent us from transitioning to a beta vs. alpha release.

Here is the list of bugs I've compiled and originally posted as comments below.

Blocker issues for LT beta

• [ ] #552 Automate silan fix during install
• [x] #42 Line-in recording
• [x] #317 ensure locale works - in theory fixed by python 3 support
• [x] #129 autoplaylist depends on API calls to run
• [ ] #461 issue with web player widget not working in certain browsers
• [ ] #71 - either have an automatic upgrade path from airtime 2.5.1 + 2.5.2 or provide documentation for a tested approach that allows people to try the upgrade w/o data loss and report errors
• [ ] #70 Watched Folders and/or CLI import
• [x] #550 Media monitor config
• [ ] #577 ensure mediafolders/watched folders configuration doesn't break LT when upgrading to LT from AT
• [x] #580 we need to have a system that works with modern distros that use PHP 7.2

• [ ] #376 - address all glaring issues in the docs where we refer to broken or non-existent features and ensure all introduced features have reasonable documentation

• [ ] #624 Provide an easy installation process that is supported aside from the install script - this could be default docker containers or debian packages or both and explicitly define what distros we support out of the box and which ones are experimental and unsupported

• [ ] #623 Provide a documented way of upgrading the software to the latest version
• [ ] #190 Provide a well documented way to backup a LT instance
• [x] #951 Merge python3 support

Since this is a subjective call we get to define the criteria. Up until now releases have been done at the discretion of @hairmare and they've been well documented and put together.

When consulting the above list also look at the related beta 3 blocker project (none are authoritative atm).

[hairmare]

I see the known issues section of the release notes as containing the main blockers for a beta. IMO it contains the issues needing a fix so all existing legacy upstream users have a way to transition to LibreTime without missing out on any features.

[frecuencialibre]

In general I think that beta releases should be reasonably bug free, ship with a UI that does not appear broken, and include the _minimum_ number of features necessary for basic functionality. Almost all feature requests should be postponed to 3.1.0 and beyond.

Perhaps we could start labeling github issues as 3.0.0 release blockers? I've also seen how using these in conjunction with github milestones also helps recently-arrived developers to get oriented quickly.

[hairmare]

Adding features before we reach beta is fine with me, waiting for 3.1.0 would be preferable but getting people to hold off implementing features they need doesn't seem pragmatic.

IMO the most important issues will be things like watched folders and line-in recording should have the highest priority since they will block folks updating from legacy upstream.

I think milestones are preferable to labels for tagging any 3.0.0 issues, an additional blocker label might make sense so we can use is:issue milstone:3.0.0 label:release-blocker to filter the issues.

[Robbt]

Ok, here is a list issues mentioned in the release notes. Feel free to add other bugs in comments that you consider show stoppers before we do a beta.
moved list to first post in this issue to make it easier to peruse

[Robbt]

We should also tag those as @hairmare recommended. I think the Silan fix would be great to automate. I'm not sure that we want to support watched folders but do think some kind of file system import is necessary. Also not sure if we should consider line-in recording an essential task since nobody appears to be working on it. The Silan and media monitor can probably be fixed by the install script.

[frecuencialibre]

For us, line-in recording and re-scheduling would be awesome, but we can wait for 3.1.0. Automatic playlists that "just work" as one would expect from the UI (ie. without the confusing need to have set them up at least an hour beforehand and have had active track changes during that time) are top priority. I know I discouraged feature requests, but since this one is already in the UI, and also frequently requested, perhaps we can include it. @Robbt sorry for the possibly obvious question, but would your proposed solution cause automatic playlists to work immediately? If so, I'd humbly request that it be prioritized for beta.

Also, I'll also add one more issue to our list: documentation: https://github.com/LibreTime/libretime/issues/376 I plan on continuing to chip away here, and see someone else also volunteered but perhaps just needs some company.

[ned-kelly]

We should also tag those as @hairmare recommended. I think the Silan fix would be great to automate. I'm not sure that we want to support watched folders but do think some kind of file system import is necessary. Also not sure if we should consider line-in recording an essential task since nobody appears to be working on it. The Silan and media monitor can probably be fixed by the install script.

Filesystem import is critical for a beta release IMHO - Any station looking to adopt Libretime from another system is going to want a quick and easy to just copy files in without having to worry about uploading through the UI etc..

[Robbt]

Hey @JohnnyC1951 I sent you an e-mail back, I was unable to find the packages you suggested were needed under trusty and they are already included under xenial (except for the software-properties-common) and thought I found an issue with the installer not enabling rewrite but realized that is not the case. Software-properties-common is used for adding new repositories and so installing this will be included if we start installing non-distro packages by default and doesn't need to be in our current install until that happens.

You could open an issue for the airtime.tmp issue as this does seem like a bug in terms of a failure to recover from a broken state with the installer script. But we need more details as to what the exact sequence of events cause this to happen and what is lost and broken by this.

[Robbt]

With regards to the auto playlist I added the issue where it depends upon track or API #129 calls to run to the blocking bugs.
With regards to whether an auto playlist should schedule whenever a new show is added that contains the playlist this could probably be done somewhat easily but this will only typically occur when someone is trying to figure out how automatic playlists work and exploring the software as people aren't usually creating shows that air right now (except when they are just trying to see how libretime works) and instead are creating shows for the future. But you aren't the first person to think "huh autoplaylists doesn't work" because it doesn't do anything immediately. So there is a need to make the model more understandable, explain it better and maybe modify the way it works for special cases like trying a autoplaylist check when a show is created. But we should create a separate issue for this.

[Robbt]

Turns out #129 isn't a problem, I'm not sure what was causing the issue in the past but recent testing confirms that indeed LibreTime will hit the API every 8 minutes and trigger the various tasks even when nothing is scheduled or longer shows are being played. So I knocked that one off the todo list.

I'd say we should make sure that we solve #71 and have a clear upgrade path from 2.5.x and also #376 so that we don't have any glaringly incorrect documentation. If we can do both of these and perhaps even get some debian packages together then I'd say we could make the transition to calling LibreTime a beta.

[Robbt]

So there has been more discussion of this topic on #552 and so I wanted to revisit this with further thoughts. I think that working towards a beta release provides us with a goal that we can focus our energy on but even if we were to fix the issues outline it's still just an arbitrary benchmark because there is no standard definition as to what represents the transition from alpha to beta. One definition is that we quit introducing features and just start testing for stability.

I think that our goal should just be to provide a working default setup that has been tried and someone who is interested in can easily install it. We're probably already more or less a beta quality in terms of many people using the software and it not being broken for their daily workflows. I think the issue is that there are still hurdles in place to make the software not easily setup in the first place.

In reflecting upon it further I would suggest that the following be our goals for transitioning to calling LibreTime a beta.

moved items from list to above checklist

So I also think the issues mentioned above are worthwhile but upon reflecting on this further I think this new list reflects the needs to transition from alpha to beta. The basic idea being that the software is easy enough to install and maintain without the end-user having explicit thorough knowledge of the Linux command line. If we can get that in place with a plan for how to maintain it for a designated amount of time then we can consider libretime to have a beta and/or even stable release.

[Robbt]

So I updated the checklist above to consolidate our work on the beta and come up with an idealistic list of what I think would be important for us to call ourselves a beta. I think that more and more people are going to be coming over from AT 2.5.1 as they realize it is essentially EOL and can't run on a modern distro.

[gusaus]

I think milestones are preferable to labels for tagging any 3.0.0 issues, an additional blocker label might make sense so we can use is:issue milstone:3.0.0 label:release-blocker to filter the issues.

Incorportating this suggestion from @hairmare https://github.com/LibreTime/libretime/issues/544#issuecomment-429404462 would also make it easier for new contributors to find issues to work on. Are there other issues that should be added to the list in the issue summary?

[gusaus]

It might be out of context for this issue, but relaunching the libretime.org website by the beta would https://github.com/LibreTime/libretime/pull/590 provide a much better showcase for users and contributors.

[Robbt]

I agree, I'll add #590 to the list. I don't think the blocker label and milestone is a bad idea and I might do it when I go through the issues again and triage them.

[gusaus]

Might also help new and/or non-developer contributors if relevent issues had labels like _help wanted_, _documentation_, _good first issue_. Many of these issues are already labeled as such.

[Robbt]

both help wanted and documentation already have labels and some things have been labelled with them I can't think of any of the issues that would necessarily make a "good first issue" because the system is rather complex and nothing pops out as easy to solve or not requiring the ability to learn a specific programming language.

[hairmare]

I can add some "good first issue" issues if we want to.

One of them could be getting rid of any require_*() or include_*() statments in the php parts (most of them can get replaced with composer autoloading).

We could also tag some things that revolve around working on the docs as "good first issue".

My experience with "good first issue" issues is that they need someone to take care of mentoring those who would like to contribute. With this type of issues the mentoring is mostly about using GitHub and best-practices regarding to coding. So not something I'm sure we need more of.

[gusaus]

Going on the assumption 3.0 is the next major milestone, would it make sense to set this up as a goal on the LibreTime collective? Skimming through https://github.com/LibreTime/libretime/issues/796#issuecomment-484676469, it seems like there was some agreement here.

https://github.com/LibreTime/libretime/projects/2
https://github.com/LibreTime/libretime/milestone/9
https://docs.opencollective.com/help/collectives/goals

[gusaus]

@hairmare @Robbt So it looks like we should remove 'beta' from this issue title!?! https://github.com/LibreTime/libretime/issues/544#issuecomment-511540941

[gusaus]

Following up on related discussion in https://github.com/LibreTime/libretime/issues/935

Should everybody with any sort of availability focus on getting 3.0 out the door before the API?

[paddatrapper]

That would be my recommendation. I'm stalled on the work I can do for 3.0 as my skills are python, and waiting on #951. That needs testing and merging before I can do more work there

[gusaus]

Are any other maintainers or contributors able to work with @paddatrapper on resolving 3.0 blockers?
https://github.com/LibreTime/libretime/projects/2

... or is this 3.0 beta?

[xabispacebiker]

I can help on a few days..

[Robbt]

Yeah at this point we just need to do some house keeping on the various issues outlined. I still think that they are all a pretty good indicator of beta level vs alpha level although it would be easy enough for someone to review one and suggest that a fix isn't needed.

[gusaus]

we just need to do some house keeping on the various issues outlined.

Based on activity here and in the forums, it seems like more folks are using and interested in LibreTime. There may even be some additional folks with time to contribute.

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?

[gusaus]

Cross-posting this forum discussion posted by @Robbt https://discourse.libretime.org/t/libretime-3-beta-todos/529

If the release blockers are up to date, it looks like only a few tasks are not yet assigned - https://github.com/LibreTime/libretime/issues?q=is%3Aissue+is%3Aopen+label%3A3.0-release-blocker

Are there others that need to be claimed and resolved before we get beta 3 out the door? Are there particular tasks where folks claiming issues still need help?

[zklosko]

Since #953 was merged, @Robbt can you please check it off for clarity?

[Robbt]

What do you want me to check off ?

[zklosko]

You got it 👍

[paddatrapper]

For the easy install point, the Debian packages in the PPA are working for both Ubuntu Bionic and Xenial. We seem to have lost the docs for it at some point though

[zklosko]

@paddatrapper When trying on Ubuntu Bionic, I got this error

postinst called with unknown argument `install'
dpkg: error processing archive /home/ubuntu/libretime_3.0.0.alpha.8-1ubuntu3_amd64.deb (--unpack):
 new libretime package pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 /tmp/apt-dpkg-install-6iDZnQ/362-libretime_3.0.0.alpha.8-1ubuntu3_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

[paddatrapper]

That was fixed in 3.0.0~alpha.8-1ubuntu4

[hairmare]

I amended the initial issue with a link to the beta 3 project board.