On 3/28/21 7:30 PM, Giuseppe D'Angelo wrote:
On 28/03/2021 20:39, Roland Hughes wrote:
On 3/28/21 12:54 PM, Giuseppe D'Angelo wrote:
Il 28/03/21 13:54, Roland Hughes ha scritto:
There is documentation and Web pages that have
replicated all over stating Qt 5 supports RHEL 6. You made something
that cannot be effectively erased untrue.
The documentation in question states that_specific_ Qt 5.x versions
support RHEL 6. There's no such thing as "Qt 5 documentation".
And ___THAT___ is the documentation and glossies management looked at
when it made the decision to use Qt in the first place. It got specified
in the Software Architecture Document.
And ____T H A T____ documentation states which Platforms are Supported
by a given version of Qt, and also for how long that given version of Qt
is supported by the Qt project itself.
Anyone over-promising based on that information has only themselves to
blame.
So what is this thread about, again? A bunch of fancy acronyms?
No. This thread is about Qt having no concept of how business actually
works. Dropping platforms mid-major version is jumping the shark, two
dolphins, and a whale.
Business needs a ***stable*** API. Nothing nuked without replacement
already in place and fully tested.
Business needs at least a 15 year window.
Business needs to know that when a major version starts out supporting a
platform that major version will support it all the way through *until
the next major version.*
QtC has created what amounts to a "no money down" entry point for phone
app developers who will at best sell 100 copies of their app then turns
around and wants north of $600K from a medical device manufacturer *sans
perpetual license.* When pressed on this it is "contact your sales rep"
which is ***NOT*** an answer. When pressed further the "support" trope
is trotted out, but as others on this list have testified there are 12
year old bugs in the database.
This thread is also about what actual Software Engineering is because
"the process" (whatever that is) has failed. One of the justifications
for ancient bugs was that the code was too complex or that fixing the
old bug would create new bugs (at least the average age of a bug in the
database would shorten).
With a valid process, that doesn't happen. The code review is not being
done properly.
Question 1: Can I understand this code?
Question 2: If I'm the last human alive with nobody to ask can I
maintain this code?
Doesn't matter what language or project, those are the first two
questions every code reviewer must ask and be able to confidently answer
yes. If not, the code cannot be approved. What too often happens in the
non-Software Engineering (AGILE) universe is a quick scan to see the
source might conform to formatting standards then a hope and a prayer
that the automated tests actually test something.
___THAT___ is how you end up with 12 year old bugs in a bug database.
Code reviews failed and allowed unmaintainable code in. The bullet has
to be bitten.
This thread is about the end of LTS OpenSource (really the end of
OpenSource Qt), the crippled Qt 6, the death of the perpetual license,
and QtC trying to club customers to death in a smoke filled room for
license fees *sans providing real support*. Real support, as viewed by
the companies QtC is trying to squeeze north of $600K out of means QtC
has to *actually fix* every bug three years old and older instead of
waiting for the OpenSource community to fix it for free. Obviously the
OpenSource process isn't going to bother.
How many bugs in the bug database are actually old enough to vote?
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
