On 10/07/2017 05:15 PM, interest-requ...@qt-project.org wrote:
On Saturday, 7 October 2017 14:58:03 EDT Andy wrote:
I don't really want to play the "pile on" game (and sorry for hijacking
the
current thread), however as someone who cares about Qt and has been using
it for a long time this is a particular source of real frustration.
Bug reports often get labelled as "Reported" and then ignored (the
"priority" only seems to make a difference if it's a showstopper, so why
have the other levels?).
Well, if we had infinite resources, we'd fix them all in priority order. We
don't, so we fix what we can. At some point, we have to draw the line and
cut a
release. So yes, lower priority items will go unfixed (unless they re
easy).
They are, however, a great way for us to get new contributors. Usually, the
lower priority items are not as complex, which allows people to "get their
feet wet" in contributing to Qt.
Thanks for the response Thiago.
Yes I understand the time constraints completely. I think some of where I'm
coming from is that there are areas that feel like they are more focused on
building new stuff at the expense of documenting & fixing the older stuff.
So the balance feels off (from the outside - I'm sure there are lots of
issues at play we aren't aware of, so maybe it's just a communication
thing).
I certainly don't want to come off as ungrateful for the work all
contributors do. It's an amazing piece of technology.
I do thank you for your work Thiago, and it is not negativity, just
frank appraisal as others in this thread have eluded to without saying
it so plainly. Adding to the stinging feeling was the recent rash of
emails from OpenSuSE and Ubuntu, most of which were automated "version
no longer supported." For a brief moment I thought I had the first ever
Linux email virus. While I didn't go back to check the date, the
OpenSuSE bugs had to be at least 6 years old because I haven't used
OpenSuSE in that many years.
Trying to contribute is often an exercise in frustration because it can
take months for even the most trivial changes and often requires constant
hounding of the "committers" to get reviewed/committed. (When it works
though it can be awesome - it really improves the quality of the
contributions.)
I understand, and like to Krzysztof, thank you for your contributions. The
fact that you are participating means others can focus on the complex
things.
I also share your pain. And to me it's worse because not only I have more
changes to get reviewed, but often I am the only person who can review the
change I made myself. According to our rules, I cannot self-approve and
must
make the effort to get others to review.
My suggestion is that you send "ping" after a week of not getting a review.
After another week, if it's still not approved, make sure the module's
maintainer (me for QtCore) or the Chief Maintainer for orphaned modules is
added to the review list, and specifically ask the maintainer for a
decision.
Two weeks is more than enough for at least some feedback.
Ok, thank you. I'm starting to do that a little more and I am seeing some
movement on things. Part of this might be cultural as well. To me bothering
someone over-and-over to do something is kind of rude, so it doesn't come
naturally:-) If that's the "accepted practice" then I'll work on my
pinging skills.
To be fair - this isn't uniquely a Qt issue - it's kind of a drawback of
the open source model in general. It would be nice to discuss it though
It's a problem which plagues every OpenSource project I have ever
utilized. The problem is epidemic at the distro level where abandonware
just keeps getting compiled and included in the next version. The KDE
tree seems to be the worst offender in that regard. KBiblio (or whatever
it is called) hasn't been maintained in over half a decade. Long ago it
ceased to work with any blog system I tried it on, yet it keeps getting
included, even in Neon. Emerald/nView (whatever) WYSIWYG Web page
editors were long ago abandoned for Blue Griffon but most distros still
include the long dead projects because someone set up the build script
to include them and they still compile. They haven't really worked in a
long time, but, there they are for the noob to pull down and be
frustrated with.
I remember one instance where a colleague made a simple one-line-comment
change, I reviewed it and said ok, then we pushed. A few minutes later,
another colleague came into our office and asked what the hell we were
thinking,
since we broke the build (this was before the CI existed).
Turns out that we forgot the "//" to make the comment a comment.
:-) Yes, certainly there are hurdles, but documentation fixes/changes seem
like they should be easier somehow. Because I don't know all the Gerrit/CI
details I'm not 100% sure how this might be accomplished.
While the comment story is horrible, it points out a rather wretched
flaw in the AGILE/TDD development method. There is no requirement for a
clean build prior to a commit. I recently left a project where
developers would hack out a change, hack out the QTest, check them in,
nag for a code review which would be very light because of all the other
time constraints only to find the automated build process died. Adding
insult to injury, a build was something like 6 hours so you could only
get 2 done per day. Adding carnage to the situation, the PC oriented
method of source control and automated builds didn't allow the ability
to regenerate the last known stable build.
I came from the big stuff. Not the massive blue iron world, but the DEC
world of global clusters long before we had the Internet. I covered the
development/code control process in this book.
http://theminimumyouneedtoknow.com/app_book.html
Boiling it down there were Development environments D01-D99, integrated
testing environments T01-T99, Production build environments P01-P99, and
Production Support environments S01-S99. Not every shop created all 99
environments because of resource limitations, but they all had command
files to auto-spin a new number up as needed.
Developers flashed from the chosen P environment to their assigned D
environment. When they "thought" they were done and could show the log
of a clean scorched earth build they would be assigned a T environment
for integration testing. Multiple D's would be assigned to the same T
(usually what was going to be included in a production turn) for
integration testing. Once it passed with user acceptance it would be
scheduled for a move to a P environment. (Usually P01. You only had
multiple P environments in use when there were massive unrelated changes
being staged over days.) After a production turn had been live for N
days it rolled to a production support environment.
I've yet to encounter a PC/OpenSource world which follows this rigor. As
a result, things get backed up.
In my experience, which seems to be the experience of others in this
thread, is the "ignoring of things" isn't an issue with the lack of
production quality rigor, but the thrill of writing new code for new
features. Nobody wants to fix bugs and even fewer people want to fix
other people's bugs, everybody wants to put their name on a new feature
and new features are what draw in new users, not stability. As a result,
bugs age off and users who needed those bugs addressed choose some other
development tool. Yes, compiled Qt is great and resource friendly, but,
when your delivery date is fixed and you can't work around a bug deemed
low priority by the maintainers, you move to a different tool for
some/all of your project.
[Thinking out loud]
Can the Sanity Bot figure out if the changes are just comments? Maybe when
submitted the commits can be marked as docs only, the Sanity bot can
complain if anything else changed, and then comment-only changes can be
batched together for integration. Would avoid the issue Krzysztof mentioned
(which I've also run into).
Maybe comment-only changes only require +1?
Like how? The only thing we can add to alleviate this problem is more
people
as reviewers. Anyone can give +1 and -1, but we don't seem to get enough
new
contributors.
I'm not sure because I'm not in the position, so I don't know all the
day-to-day stuff that's being dealt with. I feel like there are some of us
on the "outside" that are willing to spend some time & resources, but
aren't because of the frustrations. So maybe there's another way to engage
this group (assuming it doesn't just exist in my head:-) to use them more
effectively?
Lack of new contributors is a self feeding problem. Without an easily
understood production level rigor to the control and submittal process,
developers like the pair in this thread, become frustrated and stop
contributing. Without trying to beat a dead horse, a build process which
only a hallowed few understand isn't sexy or attractive.
When I left the last AGILE project I will _ever_ work on we had one guy
who was notorious for hounding everyone else to review his changes, but
boy could he ignore those automated emails to review others. He was a
nice guy and skilled developer, but if you review request had more than
3 files in it, the thing would rot in his inbox unless he desperately
needed you to review his 20+ source file change. (Changes which impacted
40+ source files were nothing there. Don't get me started.)
In a corporate environment this is an easy policy fix. Each week
developers must participate in N code reviews. It doesn't fix the
problem of everybody reviewing the code assuming the developer actually
compiled it, thus missing the fact the comment doesn't have // in front
of it, but, it is a first step.
The problem with letting code reviews rot is the fact those changes
won't be any good once something else goes in. Even if the auto-merge
works, the change can now break the other change which went in.
The second problem has been the issue others in this thread eluded to.
When their change seemed to grow moss they quit submitting other fixes.
A long time ago I submitted bug reports with some simple changes needed
in QChar. They were just some tests for characters, hex digits and
something else. I submitted them with the bug report. No idea if they
made it in. I had to create a custom derived QChar class for the
project. Most likely that product is still using that change today.
While time is always an issue, "the group" could institute a policy that
_your_ review request cannot be acted on until you have reviewed at
least one outsider submittal. The _your_ would be whoever in the inner
circle has just checked in for review. A project cannot get new
contributors if submissions don't get reviewed in a timely manner. If a
tight nit group of developers focuses on doing their own code and only
reviewing each other's code, the problem of no new contributors will
continue.
One of your comments did trouble me. I don't think I still have it in
what is left of this message, but you said something about you being the
only one who could review most of your changes. As a generalized rule,
peer review is for coding standards via diffs and checking for stupid
things like uninitialized variables as well as comments. That is what it
"should" be, especially with a large code base. An indepth code review
would also be checking against the SAG and FSD to ensure neither System
Architecture or Functional Specification were violated.
While you took insult at my appraisal at the process, I would ask you to
put yourself in the shoes of the thousands of people each day who get an
automated "version no longer supported" closure message for the bugs
they either reported or opted to follow because it impacted them. I'm
not saying they get them all from the Qt project, but given the number
of distros and OpenSource projects most of us have to use daily, we get
email onslaughts when a version goes out of scope with a massive number
of open bug reports, many of which never made it past "Reported" meaning
nobody ever looked at them to move them to "Confirmed" status.
I know it isn't vogue in the PC world, but in the big systems commercial
world, it is not unusual for companies to declare a "stabilization year"
where no product enhancements/new features get looked at. Instead, that
calendar year is spent digging through the mountain of "bugs" as either
real or "new feature" then assigning all of the real bugs to be swept
up. Why? Because today's low priority not fun to fix bug is tomorrow's
Equifax headline.
Just my 0.0002 cents.
--
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
