Tvheadend

There is a requirement for python2 or python3, same for python2-requests or python3-requests. So it's not a new requirement but now it's no longer required to have python 2 when you have python 3 (like it was before). That is important on new systems like the latest Ubuntu that would otherwise not work at all as they simply don't have python 2 anymore.

Is p3 complete backward compatible to p2 ?

Then (and ony then) you can switch from "p2 or p3" to "p3".

No it is not, and we are not switching from "p2 or p3" to p3 but from p2 to "p2 or p3". P2 is deprecated, we should not rely on something deprecated and lock out users on new systems by doing so.

The "important" scripts have a note that they are compatible with both, some scripts might need additional work though to make them compatible with both. At this point it's good enough to build a working version on the latest Ubuntu, if someone sees any issues with python 3 those should be reported at the bug tracker so they are known and can be fixed.

Switching from "P2" to "P2 or P3" doesn't makes sense at all. Immo P3 is a superset to P2.

It does make sense as python 2 is end of life and you still want compatibility for it (that's what you wrote above, no new requirements). So to get tvheadend to run on the latest Ubuntu where python 2 is not available you need python 3. So the only way to get both is a requirement of "p2 or p3", which is what I did.

Better suggestions can always be proposed as a PR and will be considered.

Flole Systems wrote:

It does make sense as python 2 is end of life and you still want compatibility for it (that's what you wrote above, no new requirements). So to get tvheadend to run on the latest Ubuntu where python 2 is not available you need python 3. So the only way to get both is a requirement of "p2 or p3", which is what I did.

I don't want compatibility with p2 - I suggested to draw a clear line when changing basic rules.

I doubt that you have understood the issue. If P2 is EOL or not doesn't makes any difference.
The point is that P3 is a superset of P2. Are you able to refuse patches which are using new
P3 funktionality ? Otherwise you may break P2 builds.

You are saying that clean P2 builds are not neccessary anymore ("P2 or P3"): thats excatly the
point where decent KM draws a new baseline....

Better suggestions can always be proposed as a PR and will be considered.

But I see: you know what you are doing.

The point is that P3 is a superset of P2.

No, it isn't. python3 is not a superset of python2. It is a different but related language. It is possible to write code that will compile and run in both environments by coding carefully and by making use of compatibility libraries (shims). But it's no longer sensible to to so (or to require to do so). It was and people have been doing it for quite a while. But python2 is now dead. It's no longer safe or sensible to compile or use anything with python2. So python3 is the only environment that matters, apart from any courtesy support for anybody who's been a little slow catching on.

JMHO: Since you apparently don't even know how to spell python, I have trouble taking anything you say terribly seriously anyway.

But making clean and separate releases in general is a good idea.

Dave H wrote:

The point is that P3 is a superset of P2.

It is possible to write code that will compile and run in both environments by coding carefully and by making use of compatibility libraries (shims).

For sure. It's possible to use another lib to solve the issue. And then use another shared Backwards Library to get rid of the issue. And then we have to have another lib which solves the issues of the first additional lib.

But it's no longer sensible to to so (or to require to do so). It was and people have been doing it for quite a while. But python2 is now dead. It's no longer safe or sensible to compile or use anything with python2. So python3 is the only environment that matters, apart from any courtesy support for anybody who's been a little slow catching on.

Obviously you don't look into the tickets - otherwise you would have seen that
there are a lot requests for 4.2. And there are much more issues which will
impact the code base. I think there already gcc10 issues.

I consider it rude to write about those people that they are "a little slow cathing on". You
don't know why they stick to old systems.

JMHO: Since you apparently don't even know how to spell python, I have trouble taking anything you say terribly seriously anyway.

Right: I don't do programming. I'm doing admin and KM stuff. This discussion is about releasehandling and requiremtenthandling.

Let's reconsider the situation:

Since month there is a serious shortage of experienced programers on tvh. It is not even possible to analyse SIG11 faults, to solve EPG issues or get improvements in the PID are. Sure: it takes a while to become familiar with the project.

Do you really think it is a good idea to - as you wrote - introduce features of "a different but related language." and throw away P2 comatibility without drawing a clear line ?

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.

But making clean and separate releases in general is a good idea.

I proposed a label already month ago.

This would have avoided the situation where new issues have to be solved in dev tree. All the p3, gcc10 extensions should better be done in dev. 4.5 - instead now everything has to be done in one codebase.

I have heard between the lines exactly your statement: "trouble taking anything you say terribly seriously anyway."

That is the difference: I know that I don't know much about programming.

Again: There are no major changes for python 3 necessary at this point, it was just necessary to tell debian that python 3 is good enough aswell. Otherwise there is no way to get the doozer build for focal to succeed. As I wanted to get all the builds to succeed again (I consider that part of bug fixing) that was important in my opinion.

Tvheadend is a huge project with parts of it being very advanced coding, so it's not easy to get familiar with everything which is necessary to do proper bugfixes. Many of the segfaults could be fixed with a simple != null check, but that is not a solution. Instead it is necessary to figure out why there is a value that shouldn't be there.

Flole Systems wrote:

Tvheadend is a huge project with parts of it being very advanced coding, so it's not easy to get familiar with everything which is necessary to do proper bugfixes.

Yes. So it is complete unclear to me why you are so keen on keeping dev 4.3.

We will see.