[Interest] PostgreSQL cross compile for Pi

[Andy]

On Sat, Oct 7, 2017 at 4:11 PM, Thiago Macieira <thiago.macieira at intel.com>
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.


> > 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
> to
> > see if we can come up with some ways to improve the process for Qt and
> make
> > it easier/"more fun" for external contributors.
>
> I wish I had ideas on how to do that.
>
> > Concrete(ish) suggestions:
> >
> >   - for documentation/comment-only changes - maybe there's a different,
> > faster path that could be introduced for these?
>
> That needs to be to non-.cpp files. That idea has merit, though.
>
> 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.

[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?


> >   - the main developers seem to be overwhelmed & pulled in 10 different
> > directions - maybe there are some tasks/processes that can be offloaded
> to
> > community members or automated?
>
> 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?


> >   - are there reminder systems for "assigned" people? Maybe a weekly
> email
> > of outstanding assigned issues sorted by priority and time-in-queue would
> > help fewer things fall off the radar? (not sure if this already exists)
> > (e.g. I have one P2 bug that's been "In Progress" since May.)
>
> Possibly, but speaking for myself, I'd just ignore that email. I already
> have
> my system and sending me more information is not going to make me work
> faster
> (but it could make me work slower).
>

Fair enough. Just throwing out ideas.


> As for In Progress bugs, sometimes the change does take long to get worked
> through. But it also happens that it's accepted and committed, but the bug
> didn't change status.
>

True. This case is neither of those, but I do understand.


> >   - 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)
>
> I can't dedicate a week non-stop to Qt, period. I dedicate 10 to 15 hours a
> week, and that's including evenings and weekends.
>

Ok - again, just throwing out ideas to try to stimulate discussion. I'm not
sure if having a huge list of "not-going-to-fix, but I'm going to leave
them open" bugs makes sense, but maybe the time trade-off isn't worth it.


> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>

---
Andy Maloney  //  https://asmaloney.com
twitter ~ @asmaloney <https://twitter.com/asmaloney>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20171007/9ee87584/attachment.html>