[Interest] Interest Digest, Vol 73, Issue 18

Roland Hughes roland at logikalsolutions.com
Tue Oct 17 17:11:13 CEST 2017


On 10/16/2017 02:22 AM, Viktor Engelmann wrote:
>> If YOU need a copy of something which clearly will not fit within the
>> confines of the bug tracker system YOU take the additional time to
>> copy it.
>>
>> Turning your argument around, what happens when your current bug
>> tracking system disappears and is replaced by something else? You
>> _still_  lose the history.
>>
> The bug tracking system is under our control - it will not just
> disappear (from our perspective).
Oh yes it will!

Speaking as someone who has heard that soooooo many times before, let's 
just count a few for Qt shall we.

The Trolltech bug database was never going to just disappear (from our 
perspective). It did. A tiny fraction of the bugs migrated to the new 
system but most were mass exterminated with

"The version this bug is reported against is no longer supported..."

The Nokia bug tracker was never going to just disappear (from our 
perspective). It did. Few, if any of the older bugs made it into the 
current database. Most were mass exterminated with

"The version this bug is reported against is no longer supported..."
We could replace it some day in the
> future, but not without transferring the knowledge to a new system. Your
> blog post might just disappear (from our perspective) - I have seen
> situations like that often enough. Stackoverflow also demands that you
> briefly state what you find on a page you link (and for the same reason).
At some point one of two things will happen. The company which currently 
owns Qt will be eaten _OR_ the OpenSource Qt project will fork. The 
second possibility is __extremely__ close to happening as I type this. 
There are an awful lot of companies, not to mention OpenSource projects 
which feel they have been completely abandoned by the powers which be at 
Qt. Indeed, many of them have been. I get a phone call 6-18 months from 
this pimp named Harmman (sp?) something or other to go work on a medical 
device enhancement. Need Qt 3 and OS/2 Warp skills. Company filed Qt 3 
bugs which weren't addressed by then owners, had to customize Qt itself 
and is now maintaining their own little spinoff because enhancements 
don't require a 7+ year clinical trial process.

I hear from quite a few companies in similar boats. They started 
development for a medical/industrial device which had a lengthy 
testing/approval process, filed bug reports for that version only to see 
them rot or fall victim to a mass extermination.

The current owners of Qt and the current OpenSource maintainers don't 
offer or seem to understand the concept of an LTS (Long Term Support) 
version. They are constantly pursuing script kiddies and that worthless 
QML instead of maintaining the base which built them. This will soon 
force a fork in the OpenSource project. One which rips out all of the 
QML and focuses on nothing but bug fixes for 12 years. Yes, 12 years. 
That's how long these environments need a stable tool set. You have a 
1-2 year development cycle, up to 7 years in clinical trials, and 5+ 
years of enhancement/maintenance product life. Enough of these companies 
are starting to run into each other or hire consultants who have worked 
at others in the same boat that the "maintain our own" philosophy is 
starting to morph into "we maintain a fork."

>
> Also, the blog post contains a lot of informations that are irrelevant
> to the bugreport (like where you got the instruction, the complaints of
> the other readers of that how-to, the complaint about the reliability of
> how-tos on the internet in general, etc.)
Well, if you think "where you got the instruction" is irrelevant then 
you aren't qualified to fix the problem. The "where" is the most 
important part as it is the official wiki. That wiki is spawning lots of 
other blog posts and wikis which are also wrong because they are based 
on it.

A single test application which uses every OpenSource database in the 
Raspbian repos along with the WebEngine needed to be used to proof the 
instructions. This wasn't done because the wiki was developed from a 
"user story" via AGILE instead of proper software methodology. As a 
result, the instructions don't work for much beyond "Hello World!"

>
> Lastly I would like to point out that improving the bug report would
> probably have taken less time than what you have invested on this complaint.
>
>
Improving a bug report which will most likely rot until the next mass 
extermination would not have helped as many people nor would it have 
provided additional content for "The Phallus of AGILE and Other 
Ruminations" hopefully being released sometime next year.

-- 
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
http://lesedi.us/
http://onedollarcontentstore.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20171017/1eceaeb5/attachment.html>


More information about the Interest mailing list