Fairly strong words from KDE side.
It seems that a necessary forking of Qt is in the possible future and could be overall a positive event.

I feel better now since I am qt and KDE dyslexic.

Only KDE visual thingy I use is a Icewm theme. plastiKo.

Would not happen.

Let's remember that KDE guys loves to reinvent their software and a new major release of Qt is their main event and fest of reinvention of wheel.

Oh, and BTW...

Isn't about first year closed, but about first year free. The Qt guys does not want anymore their LTS releases to be public supported, then we will kiss goodbye to LTS on KDE software too.

Not that the KDE really did a LTS release until now. Even with Plasma LTS and having Qt LTS, they still gone as usual with the frameworks.

So, the cake is a lie!

I don't know whether they still do (I don't really follow KDE), but KDE used to keep their own Qt tree that they applied bugfixes too. If Qt make the lts paid customers only, and delay open source release of the non-lts for 12 months (by which time it will be out of support), then I can see the need for a bug-fixed kde version of Qt resurfacing. If it does, then it will likely become the de facto version of Qt across Linux distros as no one will want to run unpatched code from upstream.

IMO, this is clear money-grab move by the Qt company: "Hey, you want bugfixes? Get your wallet out!". I don't think it'll work out for them the way they think it will, but time will tell.

4 members found this post helpful.

IMO, there is no such sentence on The American Constitution or even on its Russian counterpart, which say "A major software release shall be LTS and supported at least for 3 years"

What they say in fact is: "Hey, you want bugfixes? Upgrade to the next major version on no more than one solar year or get your wallet out!"

But the interested companies already paid and pay, then I believe honestly that this Qt company move is just a middle finger big like the Everest to the KDE plans for a last LTS release of Plasma and whatever, while they will reinvent again the wheel on Plasma6.

In few words, looks like the Qt company does not like the future Plasma6 to be rewritten from scratch, while they may be forced by the public opinion to support for an undetermined time span a particular 5.15 major release. They don't like this so much that they take now countermeasures.

I've officially run out of braincells to keep tabs on all the corporate takeovers happening in the open source community.

Qt has a strange twisted history of for-profit ownership, but in the end it seems to work out reasonably well. I'd much rather shake my fist at the anti-competitive business practices coming out of Microsoft these days. "Love" Linux? Bill Gates and Steve Ballmer are probably kicking themselves just thinking about how easy this new CEO has been able to insert microsoft into everything. One word, and everyone hands over control. Github, Ubuntu, Red Hat, and now NPM.
https://www.phoronix.com/scan.php?pa...ition-Complete

How long before Python, Qt, and GTK hand themselves over? If this shit keeps happening Slackware will be the only linux distro standing.

2 members found this post helpful.

Do you even know how git works? I don't think you do with that bit of blather.

HINT: git isn't CVS. MY repo is just as good as GitHub's.

Your git repo is just as good as the same repo on Github. Minus the issues that your git repo doesn't contain. I don't want to sound whataboutistic but imagine for a moment that at some point Github suddenly limits access to issues only. Just cloning your repo and waving bye bye won't work, the service lock-in is tight.

Are you talking about "Issues" like the bug reports on github? Because those are github specific and not tied to the repo at all with any git code. It's no different than if a mailing list suddenly disappears. But the code, the actual meaningful data, can sit on any computer in the world with all the commit history. Even if github locks everything down, anybody who has that repo locally can then upload it onto gitlab, bitbucket, host it on their own gitlab instance, or whatever other git based online solutions exist.

2 members found this post helpful.

Yes.

They are part of the project's ecosystem. The lack of them can get mitigated by great commit messages that capture as much context as possible, but even then the lack of issues (and perhaps the wiki too) makes the project feel somehow incomplete. Sure for an end user that might not matter almost at all, even the repo history won't, because all he needs is a stable release source code tarball, but once you dive deeper into a project, like for trying to contribute, reading through issues is very valuable.

Most developers just follow this workflow instead of using things like https://github.com/MichaelMure/git-bug or some other version control alternative to git that bundles issues into the repo by default, like https://fossil-scm.org

Maybe we should explain this using a method of communication that developers understand? See the following list...

Github != git
The Qt Company != Qt5
Linux Foundation != Linux Kernel
NPM != Javascript
Canonical != Ubuntu
PyPi != Python
cpan != perl
Ruby Rails != ruby
GCC != C/CPP Compilers


See pattern? The complaint here is about the company, not the code. Why are some people obsessed with screaming the words "open source FORK FORK FORK" at everyone? Do we look like we are made of disposable income?

Damn guys. This isn't rocket science.

@Pithium != making sense

1 members found this post helpful.

I think you should get out and read more. You put in the time to post 3600 messages on LQ but can't be bothered to learn the difference between Git and Github.

And we wonder why people hate slackware users so much. Can't keep our facts straight, can we?

Of course there's value in keeping bug reports, wikis, and whatever else is tied into github. Especially when a commit message is simply "Fixes #607", which then links to issue #607 and has all the details in there (but that is a poor commit message and should be avoided). The ultimate thing is the code itself. Yes, it would be a shame if the bug reports disappear, but the code can live on and any new issues can be documented elsewhere and the development can continue on.

But if you really want to ensure the Issues remain available, there's tools online that can sync those, like this one.

My apologies for giving a shit when companies push away the FOSS community. There are *definitely* no real world consequences to this kind of thing. Don't cry to me about it when the services you depend on get shut off.