- 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 <asmalo...@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.k...@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.macie...@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@qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/interest >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest >> > > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
