My opinion is that 6 years is not enough, I would target 10 years.
But I guess the core of the issue is planned obsolescence in linux internals. Namely the fear of missing out some features which require significant internal changes and which if linux is without could lower its attractiveness in some ways.
It all depends on Linus T.: arbitration of "internals breaking changes".
Do you have the resources to achieve that target and still move the project forward?
If I could ask anything from Linus it would be to be a little more relaxed about the "never break userspace" rule. Allow for some innovation and improvements. There are bugs in the kernel that have become documented features because some userspace program took advantage of that.
Arbitration, which is ulitmately in the hands of Linus T.
Where ABI stability is paramount for Linus T., ABI bugs will become features.
The glibc/libgcc/libstdc++ found a way around it... which did end up even worse: GNU symbol versioning.
Basically, "fixed" symbols get a new version, BUT sourceware binutils is always linking with the latest symbol version, which makes generating "broad glibc version spectrum compatibility" binaries an abomination (I am trying to stay polite)... because glibc/libgcc/libstdc++ devs are grossely abusing GNU symbol versioning. Game/game engine devs are hit super hard. It is actually a real mess, valve is trying technical mitigations, but there are all shabby and a pain to maintain.
Basically, they are killing native elf/linux gaming with this kind of abuse.
But I guess the core of the issue is planned obsolescence in linux internals. Namely the fear of missing out some features which require significant internal changes and which if linux is without could lower its attractiveness in some ways.
It all depends on Linus T.: arbitration of "internals breaking changes".