Can we talk about the future

@devernay ideally the less patches there Are, the easier is to maintain the project.
So I wonder the needs behind each of them:

  • why they are not merged in Qt mainstream?
  • for thus not possible, why there is an exception? Reason behind this patches?
    Are there any traces of that?

As this thread is about future, we must talk about
 CentOS6 :frowning:
It’s EOL is for the 30th November 2020. Currently it’s care stage is “security-patches only”.
So, I know FrĂ©dĂ©ric said me that CentOS6 release is the reference build, but we’ve to be lucid.
Build for this platform is like making a full OS release (ok
 I’m exaggerating a little bit, but you see).
There are tons of patches to take care (even gcc is rebuild!).

  • 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)?

Comments are welcome!

1 Like

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.

@paperdigits Packaging is also a good point, but my question is on the build itself, I’ve even not reached the packaging step


For sure, having only one packaging system to support is always a good thing for maintainers :partying_face:

@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.

2 Likes

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.

I’m repeating, Follow vfx platform CY2020 Draft only. Don’t go behind Blender, Gimp and all. Otherwise nobody will take Natron seriously.

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.

1 Like

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).

Libraries version( mentioned inside draft) are closely aligned to RedHat and CentOS.

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.

There are only two ways to go:

  1. ship all libraries (including libstdc++) with your binary. This is how flatpak works (Natron flatpak package: Flathub—An app store and build service for Linux GitHub - flathub/fr.natron.Natron), and this is how Nuke is shipped. For very good reasons.
  2. 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.

1 Like

@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, 


redistributable:

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.

4 Likes

I am just an observer but I appreciate the discussion that @yomgui is bringing.

I’ve proposed this Using Videolan Contrib system to manage 3rdparties · Issue #347 · NatronGitHub/Natron · GitHub to help dependencies management

Hi all, greetings from Norway.

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 :slight_smile:

Regards

Ole-André Rodlie

10 Likes

Hi Ole-André, great to hear from you again!
Of course you’re welcome if you can help maintaining and developing Natron and its plugins.