[Interest] PostgreSQL cross compile for Pi

[Roland Hughes]

On 10/07/2017 05:15 PM, interest-request at 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
  

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