Question about the release roadmap.

DeltaMikeCharlie · 2023-08-03T02:36:43+00:00

From the "roadmap page" it seems that the last official release was v4.2.7 dated around 16-Oct-2018 according to the GitHub record. That's getting close to...

Oliver Schinagl

Delta Mike Charlie wrote:

> That being said: What follows is my, admittedly unsolicited, opinion. No offense is meant, none will be taken.

Heh, I personally value your very product-manager like input. The general problem isn't the input or the idea's behind it; it's pure raw man-power. Who will do all these steps that you suggest? That's where the first issue starts from.

Drive-by developers that offer a new feature is great (I do it too). The long-life and risks of TVH is all based on the lack of maintainers, reviewers even testers. Writing automated pipelines is a great start for example, which would help; but who will do it?

So what is the real risk of TVH? That the current maintainers will burn-out/stop caring and leave the project, and it just rots and dies.

(What I just wrote above however, centralizing on github or something) could help in making it slightly easier to maintain, at least in a while from now ..)

Oliver Schinagl

> What would make sense is switching from our own dvb scan tables to the upstream version so we no longer need to maintain that.

Funny you say that. I am the official maintainer of the upstream dvb-scan tables. I stopped (ish, as nobody contributes) them for the most part, because your downstream mirror was more active. Obviously I don't have the bandwith if lots of MR's start popping up again :) but splitting them off of tvheadend would a) force people to submit them upstream, and b) remove the (official) burden here.

I'll restore the dvbscan tables github repo if that helps :)

Oliver Schinagl

Btw, doing releases, we can automate, I've written multiple scripts for gitlab that manages this, might be possible to port it to github with some effort. But lets not even worry about the releases, a release, in the end is just a branch/tag that 'we consider stable' and allows us to do hotfixes on a release without affecting master. But the churn on master is low, so 'meh', but not a problem.

But if these other resource-issues do not get addressed, it'll be moot anyway ...

Oliver Schinagl

Dave Pickles wrote:

> I wonder whether it is actually necessary to have these detailed mux tables; on the dvb-t and dvb-s networks I've used, tuning into one mux automatically collects the details of all the others. Just have a cut-down table with one key mux per satellite / transmitter and ask the user to tune into that to get the rest.

that's only true for some streams. But a) you still need the initial frequency, which comes from the dvb-tables; b) your network needs to squirt these out on a channel (that needs to be in the dvb-tables). :)

Saen Acro

Oliver Schinagl wrote:
> Dave Pickles wrote:
>
> > I wonder whether it is actually necessary to have these detailed mux tables; on the dvb-t and dvb-s networks I've used, tuning into one mux automatically collects the details of all the others. Just have a cut-down table with one key mux per satellite / transmitter and ask the user to tune into that to get the rest.
>

> that's only true for some streams. But a) you still need the initial frequency, which comes from the dvb-tables; b) your network needs to squirt these out on a channel (that needs to be in the dvb-tables). :)

Not all SAT positions offer NIT/FastScan or whatever automation for scan with TVH except manual frequency add.
13E and 19.2E are not only sat positions with people use ;)

DeltaMikeCharlie

Oliver Schinagl wrote:

> The general problem isn't the input or the idea's behind it; it's pure raw man-power.

I understand that now. Thanks.

DeltaMikeCharlie

Flole Systems wrote:

> Right now basically all build are broken for various reasons. I won't merge anything until someone has time to do adapt Github actions to test all PRs on all targets so such issues can be noticed before merging. I am tired of code that makes it in and then randomly breaks some targets....

Sorry, I'm no expert at GitHub. I know that when I submit a TVH PR, GitHub automatically compiles it and tells me if/where I went wrong. I see this happen when I submit a PR for Kodi as well.

When GitHub compiles a new PR for Kodi, it does so for a variety of target architectures automatically. I have run afoul of this in the past whereby a Linux change inadvertently broke something in the Windows build.

Is this what you are referring to? Having GitHub automatically build for multiple target architectures and report failures.

If so:
* What target architecture is TVH currently built for ? (Looks like just Ubuntu)
* What target architectures are missing from the automated process?

I did some reading on GetHub workflows:

In the TVH Repository, I see that there are a number of 'workflows' under the 'actions' tab. One of these workflows is 'Build Tvheadend CI' and its actions are defined in 'test-compile.yml'.

In 'test-compile.yml' there seems to be a number of instructions for building TVH for 'ubuntu-latest'.

GitHub seems to have a number of hosted runners that are available:

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#choosing-github-hosted-runners

* windows-latest or windows-2022
* windows-2019
* ubuntu-latest or ubuntu-22.04
* ubuntu-20.04
* macos-13 or macos-13-xl
* macos-latest, macos-12, macos-latest-xl or macos-12-xl
* macos-11

I suspect that this may not cover all of TVH's preferred build targets.

* Which TVH target architectures are missing from the list?
* Which of the missing target architectures would the most helpful to try first?
I volunteer to do some research into adding the most useful target architecture and we can see how that turns out. I will try to make a copy in my private repository and see if I can get it running there along side the existing 'ubuntu-latest' target. It may take a while becasue I will have to teach myself how to do it first.

Flole

We are actually compiling various targets, all that's needed now is to add a "if no cloudsmith key is defined/if it's empty" condition to the upload script and add an entry specifying "env: Cloudsmith" (see the coverity file for an example) and allow it to run on every PR. It should then run. If it does we can merge that and then I can remove the cloudsmith api key and then it should only upload master-builds but build everything on all PRs.

I believe Oliver is already on this though.

DeltaMikeCharlie

Flole Systems wrote:

> I believe Oliver is already on this though.

@Flole - OK, so Oliver is already working on a build solution. I will stand down from my previous offer regarding build targets.

Will Oliver's solution apply to all ongoing future builds? Or is this a one-off audit to see if the current portfolio of PRs cause issues?

Assuming that Oliver's efforts resolve the build issue, what's the next biggest roadblock that we can help you with?

Flole

It will affect all future PRs.

What you can do is look again at the changes from your previous PR. I left a comment somewhere where a declaration in a "for"-statement was introduced which now causes builds to fail on some platforms. Then at least there's a working master again once that and the time_t issue is solved.

I still have no clue how the documentation stuff is supposed to work (I believe I edited an automatically generated file a while ago cause I had no clue how to do it properly).

DeltaMikeCharlie

Flole Systems wrote:
> What you can do is look again at the changes from your previous PR. I left a comment somewhere where a declaration in a "for"-statement was introduced which now causes builds to fail on some platforms. Then at least there's a working master again once that and the time_t issue is solved.
>

> I still have no clue how the documentation stuff is supposed to work (I believe I edited an automatically generated file a while ago cause I had no clue how to do it properly).

I will look into my previous PRs for the issue that you mention.

Can you please provide some clarity regarding the documentation issue? Are you referring to the documentation that gets built into TVH that you can access via the WebUI?

> I don't think I have access to the translations, also the documentation needs to be "compiled".

Can you also please provide clarification on your previous statement regarding the translations?

I found this:

https://explore.transifex.com/tvheadend-foundation-cic/tvheadend/

Are you referring to the translation process or how those translations get incorporated into TVH?

Flole

There is https://docs.tvheadend.org/ but I don't think anybody has access to it anymore, so it doesn't really matter how it's built. We could use GitHub pages though, and automatically build it and upload it to some GitHub-page.

As for Transifex, I don't have access to that so no way for me to actually use it.

DeltaMikeCharlie

Delta Mike Charlie wrote:

> I will look into my previous PRs for the issue that you mention.

OK, I found it. You left a comment on a merged PR (#1544).

How would you like to proceed? Would you like to try to un-merge the PR and have me update that, or would you like me to create a new PR to fix that 1 line?

The new PR would probably be easiest for both of us.

Flole

New PR, definitely. But let's wait for Oliver to get the tests running, if you fork now and open a PR it won't be tested if the tests get added after that.

DeltaMikeCharlie

Flole Systems wrote:

> New PR, definitely. But let's wait for Oliver to get the tests running, if you fork now and open a PR it won't be tested if the tests get added after that.

OK. If you let me know when Oliver is finished. I will raise a new PR with the required fix.

Jonas Lang

Guys we are now seeing real debate and collaboration instead of moaning and criticism. Hopefully this behaviour gets some traction and gets TVH back on track again.

Those who “can do” have identified themselves so hopefully this is the beginning of new approach to the project.

Remember there is a considerable user base who are members of the forum and I am sure would be only too glad to assist in testing if invited to do so. Do bear in mind that they are not developers or coders but do have something to offer. Their time too.

Hopefully together we can unravel the hidden mysteries of the TVH project together. Thanks again for the input.

DeltaMikeCharlie

Delta Mike Charlie wrote:

> When GitHub compiles a new PR for Kodi, it does so for a variety of target architectures automatically. I have run afoul of this in the past whereby a Linux change inadvertently broke something in the Windows build.

I have, coincidentally, just submitted a PR to Kodi. Here are the targets that it automatically builds for:

* android-arm-docker (android-arm-docker)
* android-arm64-docker (android-arm64-docker)
* android-x86-docker
* webos-docker
* LINUX (LINUX-64-GLES)
* FreeBSD
* IOS-ARM64
* WIN-32
* OSX-64
* TVOS
* WIN-UWP-ARM
* OSX-ARM64
* WIN-64
* LINUX (LINUX-64-GL)
* WIN-UWP-64
* WIN-UWP-32
* LINUX (LINUX-aarch64-GLES)
* LINUX (LINUX-arm-GLES)

Saen Acro

@ user#35408 see this
https://tvheadend.org/issues/6288#note-3

Oliver Schinagl

pipelines are now enabled for all MR's.

What would be nice is Mac OS builds and FreeBSD builds :) since people complain about breaking exotic systems, but we have no proof thereof.

Anonymous

Flole Systems wrote:

> There is really no point in trying to maintain 2 branches if there aren't even enough resources to maintain a single one. Also I have absolutely no clue how a new release needs to be done. I assume it somehow involves branching, but that's probably not all that's needed.

I have seen lots of projects dying. Usually the last phase starts with quick-fix-wins which are introducing new and fancy features. With people telling that the others are "slow" and yesterday. Next step are commits that leads to surprising sideeffects - which noone is going to fix: the experience ramp up takes a while.

« Previous Page Next Page »