[Interest] PostgreSQL cross compile for Pi

Sun Oct 8 13:06:23 CEST 2017

  - 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").

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

On Sat, Oct 7, 2017 at 8:58 PM, Andy <asmaloney at gmail.com> 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?).
>
> 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.)
>
> This has been my experience over the years. I really want to contribute,
> and I try, but it's certainly not a lot of fun (which calls to mind Lars'
> talk at CppCon where one of the goals of the Qt project was to "Make
> Software Development Fun & Easy").
>
>
> 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.
>
> Concrete(ish) suggestions:
>
>   - for documentation/comment-only changes - maybe there's a different,
> faster path that could be introduced for these?
>   - 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?
>   - 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.)
>   - 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)
>
>   - (insert your suggestion here)
>
> ---
> Andy Maloney  //  https://asmaloney.com
> twitter ~ @asmaloney <https://twitter.com/asmaloney>
>
>
> On Sat, Oct 7, 2017 at 1:27 PM, Krzysztof Kawa <krzysiek.kawa at gmail.com>
> wrote:
>
>> I don't want to be mean Thiago, because I love Qt, I do appreciate
>> your hard work and all the people that make it happen, but you need to
>> consider that you're pretty big part of Qt and things around you do
>> move in a different pace. It's not the same for some of us.
>> As an example consider this P2 bug:
>> https://bugreports.qt.io/browse/QTBUG-52108. I reported it in 5.6.2.
>> It's 5.10 alpha now and it only deteriorated further.
>> You could say "well then fix it yourself". I did try to start
>> contributing. Take a look at this sad change log:
>> https://codereview.qt-project.org/#/c/196430 - the most absurdly
>> trivial 4 words of comment and it took almost 2 months to review it
>> (see by who btw.) and I gave up after 7 tries to stage it. Sorry, but
>> I can't imagine what it would take to add anything of substance this
>> way.
>>
>> 2017-10-07 18:51 GMT+02:00 Thiago Macieira <thiago.macieira at intel.com>:
>> > On Saturday, 7 October 2017 05:49:00 PDT Roland Hughes wrote:
>> >> I expect, like all OpenSource bugs, it will be ignored until the
>> version
>> >> it is reported against is no longer supported, then it will become a
>> >> "closed" bug.
>> >
>> > Except for all the bugs that I close, which are only about the open
>> source
>> > version. As much as possible, I work on them immediately.
>> >
>> > Example: *this* week in the thread "QUdpSocket on Windows 10:
>> > QNetworkDatagram::destinationAddress/Port not set", I asked that a bug
>> be
>> > reported. It was (QTBUG-63605). I've already fixed it. It's making its
>> way
>> > through the verification and will be in the next release (5.9.3).
>> >
>> > So please take your negativity away and stop insulting those who
>> actually care
>> > about Qt.
>> >
>> > --
>> > 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
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20171008/f23f17e5/attachment.html>