On 10/08/2017 10:41 AM, interest-requ...@qt-project.org wrote:
- schedule a triage week every couple of months to go through the current
backlog and reassess/re-prioritize? (again, don't know if this is done -
doesn't seem like it from the outside)
This should maybe also include the bugreports whose assignee went missing
years ago and are just stalled (or worse, "closed due to inactivity").
Yes, once the 12 year old boy who volunteered to fix it actually
discovers girls, well, their interest in programming vaporizes...<Grin>
I must say in choir with the others posters here that I wanted to
contribute a bit but I'm honestly giving up after some weeks of doing
changes -> calling maintainers -> maintainers suggest another set of
changes, etc., mostly because this means that by the time my patch actually
ends up in a released version of qt it's almost a year (plus realistically
a few more months waiting for the usual patch releases to sort out problems
with macOS 10.18 "Random Waterfall")... I may not even be working on qt
software (or software at all) so far in time so the effort / reward ratio
ends up being less interesting than contributing to projects where the
whole "propose patch -> CI & sanity check pass -> patch applied" process is
a matter of hours.
I guess this is due to the "industrial" requirements of many Qt users,
though in my small experience I already saw the following happen:
* business B uses a tech A for years and lobbies against big updates and
breaking changes "for stability concerns"
* developers of tech A want to keep the business as a client so they limit
changes to the max
* developers at the business B, etc are slowly getting fed up with working
with software full of old practices and legacy bugs
* in the meantime some other shiny new tech is being developed by random
guys on a github repo
* tech debt at business B accumulates, developers are even more fed up when
they look at the new tech which looks oh so shiny
* one day a dev of business B does a proof of concept of a remake of their
software with the new tech and show it to B's business owner while telling
them "it took 1/10th of the time it takes to develop with tech A!"
* business B decides a complete switch from tech A to new tech and the
company that develops tech A gets less and less clients and are reducted to
using predatory practices to keep their clients.
This could (maybe, maybe not...) have been averted if tech A had more
ambitious updates that did not fear doing breaking changes from time to
time to make the overall thing easier to use.
Best,
-------
Jean-Micha?l Celerier
http://www.jcelerier.name
Jean,
An interesting perspective. On the PC side of life, I have no doubt it
is true. On the big systems side of life, it will never be true. Y2K
happened because management kept saying "oh we're gonna replace that
system" whenever developers said "we need to fix this." All of the
replacement systems failed so a mad rush of patching occurred. Another
mad rush will happen around 2027 if you feel like doing COBOL. Don't
know why, but 2027 seemed to be the hack year chosen for most entry
screens which did not have room for a 4 digit year. Wanna know why it is
going to happen? "Oh, we're gonna replace that system."
Core business systems get replaced under these conditions:
1) The company drops an entire business line. (The Chicago Stock
Exchange got rid of its trading floor, moving to a completely automated
system without specialists or any floor personnel. The "temporary"
trading floor system which started out on the PDP in the 1970s, moved to
the VAX in the 1980s, the Alpha in the 1990s and the Itanium processor
in the 2000's finally hit the end of its "temporary" life.)
2) The company is eaten by a larger/more cash flush corporation which
forces them onto the corporate system.
3) The hardware and OS vendor goes out of business without any third
party emulators. Think Wang computers and even Singer computers. If you
want more modern examples, Oracle is pulling the plug on SUN Sparc so
systems which relied on the massive threading capability of the platform
have to either die or be reworked to run on lesser platforms.
Software is used to run a business which makes money doing something
else, so there is no incentive to jump ship. Technically, you can
continue to run long after the hardware and OS vendor has went out of
business as long as there are third party hardware maintenance companies
with a stock pile of parts. I know one CAT location is rumored to have
used a certain model PDP to control all its drilling and milling
equipment at their Aurora, IL location. Story goes when DEC announced
they would make no more CAT went out and bought every used one they
could find, parked them in a storage location and cannibalized them for
parts for the next twenty some years. They are in the process of closing
that work or the plant down, have slowly been for years. That is how the
PDP's eventually stopped being used.
On the PC side of life, we have similar situations for both industrial
and medical. Industrial test equipment (and there is a lot of it) needs
to be stable and certified. When it is going into some kind of assembly
line or plant, the buyer wants the _exact_ same interface on each unit
even if it does different things based on where it is in the line. They
want to be able to move factory workers at a moment's notice.
In the FDA regulated world, you have the clinical trials process each
change must go through. For surgical robots that involves a bunch of
cadavers first for your own internal testing, then for FDA approval and
whatever else the FDA wants done. (Not as easy as it might sound. You
have to wait for people to die with the organs you need in their
original locations __and__ they have to have willed their body to science.)
Personally, I do not remember the FDA testing and approval process for
this device:
https://www.welchallyn.com/en/products/categories/patient-monitoring/vital-signs-devices/connex-spot-monitor.html
I remember I was told at some point, but my job was only to write
roughly half of the C++/Qt UI code adhering to all of the FDA
development regulations, fixing anything the independent QA team found.
In the medical device world, you have automatic updates turned off in
your Linux development environment. That "move quickly and break things"
shit causes millions of dollars worth of problems. Sometimes it even
leads to products which get onto the market then appear in those late
night personal injury lawyer commercials.
While I don't doubt you have seen what you say, I would like to point
one thing out:
* developers of tech A want to keep the business as a client so they limit
changes to the max
* developers at the business B, etc are slowly getting fed up with working
with software full of old practices and legacy bugs
Developers of tech A did _exactly_ what Qt is doing now which means they
are doing it wrong. "Limit changes to the max" means they focused on
shiny new features while letting bug reports rot. I submit the phrase
"legacy bugs" as proof. While "old practices" may or may not be
changeable, they do not drive a business from a technology. I just went
to indeed.com in a browser I had never used to get there. Searched for
"cobol programmer" without any location.
Full-time (218)
Contract (85)
Part-time (10)
Temporary (6)
Commission (2)
Internship (1)
"fortran programmer" no location
Full-time (43)
Contract (3)
Part-time (2)
Commission (1)
Temporary (1)
"forth programmer" no location
Full-time (95)
Contract (7)
Part-time (4)
Commission (2)
While many of today's "script kiddies" can't be bothered to learn
disciplined software development, enough can and do. I chose those
languages because phone and Web people consider them dead tech. They
seem to ignore the fact COBOL runs almost every (probably every) payroll
system on the planet. FORTRAN is still massive in the scientific and
research communities because it has capabilities no other language
possesses. At least the commercial proprietary platform versions do. The
GNU version cannot have more capabilities than the C language back end.
(Yes, I know they p-compile things to the GNU language and that gets
compiled by the back end, but the original back end was for the C
compiler...no need to veer off in minutia.)
Believe it or not, FORTH is still used in a _lot_ of embedded systems
__and__ AI.
indeed.com sucks when it comes to searching for ADA. I see it constantly
in the DOD/military contractor postings, but you just can't search for it.
Sorry, I guess I did veer off a bit.
At any rate, the powers that be behind Qt have chosen to add "sexy new
features" at the expense of bugs. Mostly this is to chase new markets
which will have a catastrophic effect on the product. You cannot serve
multiple masters.
QML was a mistake of biblical proportions. I've heard all of the bogus
justifications about "further segregating interface" blah blah blah. The
truth is script kiddies don't have the discipline to learn C++ so they
tried to change Qt into a script kiddie friendly product. Ironically
they did it to chase the phone market. I say ironically because QML is a
yuuuuuuuuuuuuuuuuuuge resource pig.
http://www.logikalsolutions.com/wordpress/information-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/
Frack! When I migrated to a new host the video player plug-in wasn't
compatible. I need to poke around for a new one tomorrow to fix that
post so you can see the indescribably wretched performance of QML on a
Pi 2 vs. the same application compiled from C++ and widgets. You can at
least pull the code down and try yourself.
QML's massively intense resource consumption inhales battery life so the
choice of app developers seems insane. Idiot phones are now having
battery life measured in minutes while flip phones have about 2 days
worth of talk, not stand bye, time.
Personally, I've never seen the point in chasing the phone market. Your
app has the lifespan of a fruit fly. The next forced out
Android/Apple/whatever update will break it. Windows Mobile has been
abandoned. Google is dropping Android, moving to Fuchsia (sp?) in the
next year or so. Ubuntu is also moving to Fuchsia, abandoning Linux.
Windows isn't even going to be Windows 2 years from now. It is going to
be a Microsoft front end on top of what used to be Ubuntu Linux. They've
already started the process with Windows 10. Adding insult to injury
phone developers push for a zillion "cool new features" in Qt adding
even more bugs to the pile of bugs currently being ignore while
developers slave away trying to add those "cool new features."
In short, they are "developers of tech A" in your example. The existing
medical, industrial and agricultural device industry using Qt (massive
by the way) will not be able to continue using the tool because the
pursuit of "cool new features" blocks the bugs they need fixed. Today's
phone operating systems will cease to exist within two years, requiring
a soup to nuts redevelopment of Qt adding more bugs.
Personally, I don't know what Apple is moving their iPhone to, nor do I
care. I know that every phone OS vendor is seeking "one ring to rule
them all" right now. A single OS for Phone, laptop, desktop, server, and
IoT. Ubuntu had to punt on their phone
http://www.techradar.com/news/canonicals-dream-for-an-ubuntu-phone-is-dead
so they have their own fork of Fuchsia (sp?)
Unit was a grotesque desktop so I'm kind of glad it all failed. Now if
Neon could fully divorce itself from Ubuntu...
--
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
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
