how many maintainers other than me has the time/knowledge to support it?
even with maintainers, whatâs the time to support it for only 1.5 year of support? (after EOL, repos can disappear, no ones is able to (re-)install it)
Since yesterday Iâm fighting with invalid URLs and Natron build system to make a SDK, I even not started Natron itself.
You see, using another reference platform for the GNU/Linux is a mandatory step right now.
Question: which reference platform? And how to choose it?
Should we go with a LTS style? Using a 10-years support like what Redhat does is appealing but you may skip important technology evolutions. Ubuntu (well even if I personally dislike it) has a shorter support timeline for LTS (but some discussions are made to extend it to 10 years).
Do we need (for Natron itself) sort of care (really! itâs an important point)?
I am sure this opinion will be reviled by a few, but why not target one of the new packaging formats? Natron is already packaged up for flatpak. Snap shouldnât be much harder and Canonical would likely help you with the initial packaging if you run into issues. @probonopd would probably chip in for an AppImage as well. This makes âdistro supportâ less of an issue.
@yomgui I donât want to derail this thread, but flatpak is packaging and building. You basically build everything from source. You can updated each individual dependency, build it from source, and then run the resulting application. Itâs sort of a âclean roomâ build, independent of any particular distro and their library versions.
@paperdigits yes, itâs both, but it doesnât change my point. Letâs me explain the problem in another way.
Here the point is all about handling dependencies: vanilla build or flatpack doesnât change the issue.
If a needed library is not available on the runtime host, you need to embed it inside you packaging (thatâs flatpack gives you. Flatpack gives also âsandboxingâ concept, but itâs not a major requirement, at least nothing related to dependencies issue).
So when you embed a library, immediately you gain the maintainer role of this library.
This is where all problems come: you need to follow the life of them, find when a security fix comes, handles patches when you change the version, etc.
Itâs exactly what I did during 5 years on a previous FOSS project, and I can say itâs complex for only few deps, itâs a nightmare for many⊠or you need a full-day work team (exactly what I get on my project⊠and they was paid for!).
For a FOSS without a budget, forget it.
Support many deps was an old habbit in FOSS. Itâs not feasible now with so many subprojects.
Let distributions taking this role, they have the power to do it.
Please use CentOS 7 or RedHat 8 beta, if you want to make Natron fit within industry standard.
Ubuntu, Flatpak, Snap, etc are not for serious user, it just for fun and hobby project.
And according to CY2020 Draft, Python 3.7 is future, So we also need to upgrade Python version.
The Gimp team is very pragmatic at the point of the build system.
Debian Testing is the reference for the developers. (Ubuntu is based on Debian Testing.)
Windows, macOS and Flatpack packages are build by team members.
Every thing else is the job of the distributions/packagers.
The VFX Platform FAQ says they donât recommend a platform. It seems disingenuous for you to recommend a distro and use them as a backing for your argument when they donât even recommend a particular distro.
Further the FAQ says that Ubuntu is used heavily in the industry alongside RHEL and CentOS.
I am not quite sure what the discussion is about here: If Natron is supposed to be VFX Reference Platform compatible, it has to be buildable with the listed versions of the tools. So any distribution providing these tools should be just fine. I mean in the end many distros will anyway build from source on their platform, itâs not like thereâs any exclusivity. Maybe I am just naive because all OSS software I worked with was comparably simple, but the way I know it works is that you just specify your dependencies with version requirements (which could point to VFX and then just specify whatever isnât part of that).
You cannot use a single system library, except libc and the Xorg libraries, if you want a redistributable binary. This is also a lesson we learned dring Natron development.
build as many distribution-specific packages as there are distributions, relying on the distribution-provided libraries. Good luck with that.
As for the Qt patches, the last version of Qt 4 was released in May 2015, and lots of bugs were discovered and fixed since. Natron also needs a patch to the thread pool to run more efficiently. The Debian and Fedora packages for Qt4 also contain lots of patches, and none of these will ever be applied upstream. In fact, the patches we ship in the SDK are a merge of the Debian patches and the homebrew patches (filenames and file content was left untouched, so you can track back the source for each of these). Still, Qt4 was the only option until the recent release of Qt 5.12, because of the lack of python support in Qt5, and it is a very stable set of libraries.
Of course, everything should be moved to Qt5+Python3 in the near future, but you should first learn how to make redistributable binaries. This is no easy task, believe me. Then you should understand the code. Then you can move to Qt5+Python3. We (the developpers) were also experimentally compiling using Qt5 and Python3, so there is very little work to be done (you will find parts of the code that are python 3 or Qt 5-specific)
Concerning the choice of CentOS 6 for building the binaries, this does not have any impact on the end-user. We are not talking of using CentOS 6 here, just compiling the SDK and the source code. You should continue building the binaries on CentOS 6, even if users are running it on the latest ubuntu or fedora or whatever: this has no impact on the users, and this ensures the best compatibility across all running Linux systems. The Foundry does the same for its Nuke builds, and no user ever complained about compatibility issues, or complained that their software is outdated: System Requirements | Nuke | Foundry
Unless there is a serious advantage from using a more recent system for building Natron, this should not be upgraded. When Nuke moves to CentOS 7 as its minimum OS version, then maybe itâs time for Natron to make the same move.
@devernay What do you mean by âredistributable binaryâ exactly?
technical or legal issue?
Blockquote
Unless there is a serious advantage from using a more recent system for building Natron, this should not be upgraded. When Nuke moves to CentOS 7 as its minimum OS version, then maybe itâs time for Natron to make the same move.
whooo! Sound like âwhat Nuke does, we do the sameâ. Itâs a bit harsh. What is/are reason(s) behind that?
The problem of this sentence is the definition of âserious advantageâ: there are as many definition as there are users/developers/copyrights-holders, âŠ
We thought exactly the same thing and though we were more clever than the Nuke guys. Our first binary distributions were Ubuntu-based (probably 12.04 or 14.04 at that time). We finally figured out the reason. This is really the only way to get linux binaries that run everywhere. Now if you think you are better than the guys at the Foundry, then try it (and donât forget youâll have to test it on dozens of Linux distros).
Once again, just think about that: what is the cost of building on CentOS 6 (or 7) versus any other distro? nothing
@devernay I understand your point. On my side, I prefer to not enter into âclevernessâ of people discussion.
For me, each situation requires to make choices and understand the consequences of them.
Sure, building host is not an issue. And thatâs also my point.
Where Iâm worried is all about âcare effortâ required in current situation.
Making decisions based on what a firm with incomes and closed sources does is not a model sustainable in the situation of Natron: genuine developers busy on paid job, few dev/care from others (by judging it from github and openhub statistics).
I know making decisions is not as easy as we may think. That why I ask you all these questions to understand the dev history of Natron.
I think living in FOSS environment with a model based on closed-source/non-free competitors is a dangerous choice.
Itâs my view (well⊠based also on my experience), I understand if someone is not agree with me.
So now, to return to some âbetterâ news. Iâm able to build for CentOS6 and Fedora 29, first one with almost all debs build inside (current SDK model), second one with almost all from system (event Qt4, yes I know the point of ThreadPool patchâŠ).
As I canât test CentOS6 version (I donât want to spent time to install it), Iâm testing the Fedora.
Works almost well, even if I got few crashes (when playing with ffmpeg reader when the frame is crossing the end of the stream). I continue to read the code to make me more familiar with it.
Iâm one of the âlostâ devs from Natron, that due to several reasons I cannot discuss in public had to leave the project. Itâs sad to see Natron in this state (I was not aware), I though that Natron would be doing much better by now.
First of, @devernay I Salute you! for continuing the development, very few people know how much hard work that is, and you have done it alone for a very long time. I think it time to take some of the burden of your shoulders. Also, Iâm sorry for just popping up here after years of silence, I hope no hard feelings (I meant no harm, just personal/work issues that escalated beyond my control).
Iâm willing to use some of my spare-time to help maintain Natron again, I canât let this project just die, we have all dedicated too much time to this project just to see it fade away.
Give me a list of the most critical things that needs to be done (start with infrastructure and build).
Btw, I have not used Natron since 2.1.9, so be gentle