Re: [Development] Co-maintainer of QtNetwork

[Alex Blasche]

+1

--
Alex


From: Development  on behalf of Timur 
Pocheptsov 
Sent: Thursday, 20 February 2020 06:48
To: qt-dev
Subject: [Development] Co-maintainer of QtNetwork

Hi all,

I want to propose a colleague of mine, Mårten Nordheim, as a co-maintainer of 
QtNetwork module with him
becoming the maintainer of  „High-Level network access (HTTP)"* (which 
essentially means QNetworkAccessManager
and related classes/code, sub-module 'access' etc.)  component and me 
continuing as the maintainer of  "Low-level
access (Sockets, SSL, Hostname resolution, Bearer mgmt, etc)"**. Since the 
first day he joined the Qt Core
and Network team several years ago, Mårten is making a significant contribution 
to the QtNetwork module, which
includes numerous improvements and fixes in QNetworkAccessManager and also new 
developments (among other things
he is the author of SChannel TLS backend on Windows). He has a good, solid 
knowledge of QtNetwork code/components
and making him the maintainer "de jure" will help us (the Qt Core and Network 
team) to optimise and streamline the
future developments in QtNetwork module.

Best regards,
   Timur.

* and ** - these are names taken from our wiki page on the Qt maintainers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Co-maintainer of QtNetwork

[Lorn Potter]

+1

On 20/2/20 3:46 PM, Timur Pocheptsov wrote:

Hi all,

I want to propose a colleague of mine, Mårten Nordheim, as a 
co-maintainer of QtNetwork module with him
becoming the maintainer of  „High-Level network access (HTTP)"* (which 
essentially means QNetworkAccessManager
and related classes/code, sub-module 'access' etc.)  component and me 
continuing as the maintainer of  "Low-level
access (Sockets, SSL, Hostname resolution, Bearer mgmt, etc)"**. Since 
the first day he joined the Qt Core
and Network team several years ago, Mårten is making a significant 
contribution to the QtNetwork module, which
includes numerous improvements and fixes in QNetworkAccessManager and 
also new developments (among other things
he is the author of SChannel TLS backend on Windows). He has a good, 
solid knowledge of QtNetwork code/components
and making him the maintainer "de jure" will help us (the Qt Core and 
Network team) to optimise and streamline the

future developments in QtNetwork module.

Best regards,
    Timur.

* and ** - these are names taken from our wiki page on the Qt maintainers.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development



--
Lorn Potter
Freelance Qt Developer. Platform Maintainer Qt WebAssembly, Maintainer 
QtSensors

Author, Hands-on Mobile and Embedded Development with Qt 5

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Co-maintainer of QtNetwork

[Shawn Rutledge]

+1

On 20 Feb 2020, at 06:48, Timur Pocheptsov 
mailto:timur.pochept...@qt.io>> wrote:

Hi all,

I want to propose a colleague of mine, Mårten Nordheim, as a co-maintainer of 
QtNetwork module with him
becoming the maintainer of  „High-Level network access (HTTP)"* (which 
essentially means QNetworkAccessManager
and related classes/code, sub-module 'access' etc.)  component and me 
continuing as the maintainer of  "Low-level
access (Sockets, SSL, Hostname resolution, Bearer mgmt, etc)"**. Since the 
first day he joined the Qt Core
and Network team several years ago, Mårten is making a significant contribution 
to the QtNetwork module, which
includes numerous improvements and fixes in QNetworkAccessManager and also new 
developments (among other things
he is the author of SChannel TLS backend on Windows). He has a good, solid 
knowledge of QtNetwork code/components
and making him the maintainer "de jure" will help us (the Qt Core and Network 
team) to optimise and streamline the
future developments in QtNetwork module.

Best regards,
   Timur.

* and ** - these are names taken from our wiki page on the Qt maintainers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Co-maintainer of QtNetwork

[Timur Pocheptsov]

Hi all,

I want to propose a colleague of mine, Mårten Nordheim, as a co-maintainer of 
QtNetwork module with him
becoming the maintainer of  „High-Level network access (HTTP)"* (which 
essentially means QNetworkAccessManager
and related classes/code, sub-module 'access' etc.)  component and me 
continuing as the maintainer of  "Low-level
access (Sockets, SSL, Hostname resolution, Bearer mgmt, etc)"**. Since the 
first day he joined the Qt Core
and Network team several years ago, Mårten is making a significant contribution 
to the QtNetwork module, which
includes numerous improvements and fixes in QNetworkAccessManager and also new 
developments (among other things
he is the author of SChannel TLS backend on Windows). He has a good, solid 
knowledge of QtNetwork code/components
and making him the maintainer "de jure" will help us (the Qt Core and Network 
team) to optimise and streamline the
future developments in QtNetwork module.

Best regards,
   Timur.

* and ** - these are names taken from our wiki page on the Qt maintainers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Co-maintainer of QtNetwork

[Timur Pocheptsov]

Hi all,

I want to propose a colleague of mine, Mårten Nordheim, as a co-maintainer of 
QtNetwork module with him
becoming the maintainer of  „High-Level network access (HTTP)"* (which 
essentially means QNetworkAccessManager
and related classes/code, sub-module 'access' etc.)  component and me 
continuing as the maintainer of  "Low-level
access (Sockets, SSL, Hostname resolution, Bearer mgmt, etc)"**. Since the 
first day he joined the Qt Core
and Network team several years ago, Mårten is making a significant contribution 
to the QtNetwork module, which
includes numerous improvements and fixes in QNetworkAccessManager and also new 
developments (among other things
he is the author of SChannel TLS backend on Windows). He has a good, solid 
knowledge of QtNetwork code/components
and making him the maintainer "de jure" will help us (the Qt Core and Network 
team) to optimise and streamline the
future developments in QtNetwork module.

Best regards,
   Timur.

* and ** - these are names taken from our wiki page on the Qt maintainers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtLocation / QtPositioning and Web Assembly

[Lorn Potter]

On 19/2/20 6:49 PM, Sebastian Kügler wrote:

Hi,

I'd like to create an application using the MapView QtQuick plugin and deploy
that application using the Web Assembly platform. It seems, though, that the
QtPositioning and QtLocation modules are not (yet?) available for WASM.

- Did anybody already get it to work?

Most likely not yet.


- Is this planned by anybody?
It has been in the back of my mind for some time now, but I just created 
a JIRA task if you want to comment, or vote for it.


https://bugreports.qt.io/browse/QTBUG-82358


- What would be the steps / likely time investment, etc. to be able to use
these modules in a WASM-deployed application?


The hard part would be implementing the positioning backend using 
javascript API, which is quite limited in comparison to other sources. 
It lacks satellite info for one. So at least it would not take all that 
much work to get basic functionality. On par for the serialnmea plugin.





Thanks in advance,



--
Lorn Potter
Freelance Qt Developer. Platform Maintainer Qt WebAssembly, Maintainer 
QtSensors

Author, Hands-on Mobile and Embedded Development with Qt 5

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW

[André Pönitz]

On Wed, Feb 19, 2020 at 06:26:56PM +0200, Konstantin Ritt wrote:
>  Should we ever try to work around issues caused by broken CPUs?

Yes.

Because "CPU is broken" one way or the other is rather the common
case. Declining to work as best as reasonably feasible in this
situation might as well end up with an empty potential user base.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: more Jira states to track stages of the work on an issue

[André Pönitz]

On Wed, Feb 19, 2020 at 10:43:17AM +, Volker Hilsheimer wrote:
> Even when doing development (as opposed to the pointy-haired work), I
> benefit from having tools that help me to maintain a work-in-progress
> limit, that allow me to see what state the work someone else is doing
> is in (because I might depend on it or just be curios about it), or
> allow me to signal to customers waiting for the fix that they might
> want to have a look at a proposed change, even if they don't have an
> account on Gerrit.

*Customers*, *without an Account*, to *look* at changes on Gerrit?

Sometimes I really regret having dropped out of university before
finishing basic maths.

> The Qt Project defines “code review” as an explicit step that
> contributions have to go through.

Correct.

> Given that it takes a substantial amount of time to get things
> through review,

A review, even a *proper review* by *your standards*, does not have
to "take substantial amounts of time".

It's technically completely feasible (and I guess one could dig out
practically examples) where an issue goes from "Someone mentioned
a problem on IRC" to "Fix is integrated" in less then five minutes.

The undeniable fact that it actually *does* take a substantial amount
of time *in a lot of cases* is not the result of having "not enough
JIRA states" but actually that of a lot of causes, none of which that
I am aware are of of the sort that would benefit from changes to the
JIRA process.

> I think it would make the JIRA-model of how work happens a bit more
> useful if it would reflect the way that work actually happens.

That's an interesting puzzle to solve when "the way that work actually
happens" is actually "outside JIRA, for a reason"

And that happens to be rather normal when e.g.
  - the issue is not coming via JIRA, like normal reviews,
  - the issue is urgent so JIRA would be too slow to use,
  - the issue is small, so the overhead would be prohibitive
compared to the cost of the actual work.
  - the issue is big, so wind direction would change to often
before this is done.


Andre'
> 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW

[Thiago Macieira]

On Wednesday, 19 February 2020 08:26:56 PST Konstantin Ritt wrote:
> Should we ever try to work around issues caused by broken CPUs? Maybe we
> should warn the user instead (with big red banner) and decline to install
> anything at all?

That was the thinking on the first task. We thought it was a small corner case 
and that it would be simply fixed by the few people with a BIOS upgrade.

When it turned out to be much more widespread and systemd also worked around 
it, we did too.

> >  (or buy Intel)
> 
> Or let's maybe also try to work around Meltdown and Spectre on i, just for
> symmetry? ;)

a) we don't have to for most of Qt, since the mitigations for them are done in 
the kernel and microcode updates already. The only exception is anything that 
JITs untrusted sources. Namely, qtwebengine. But I believe the mitigations are 
already present in the Chromium sources we use.

b) Spectre (one of the two or both) also affects AMD and ARM and every single 
out-of-order processor system out there. Please see the technical docs for 
more information.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: more Jira states to track stages of the work on an issue

[André Pönitz]

On Wed, Feb 19, 2020 at 09:45:48AM +, Edward Welbourne wrote:
> On Tue, Feb 18, 2020 at 01:11:29PM +1000, Lorn Potter wrote:
> >> Stepping through the interim steps is not a requirement, so it is not that
> >> much difference to go from Reported->In Progress to Reported->In Review,
> >> really.
> >>
> >> So the list you have to select from has one more entry to choose from, is
> >> that such a big deal?
> 
> > This is not the problem.
> >
> > More states lead to bikeshedding what would be The Right State for a
> > task.
> 
> I very much doubt the distinction between In Progress and In Review is
> going to involve much bike-shedding.

*shrug*

Assuming that JIRA states are meant to be disjoint and that the names
actually bear some meaning, "In Review" would mean "Not in Progress".

Which already would be an interesting message to the reviewer. Like,
"whatever you do here, that's not considered 'Progress'".

Of course, nobody intents to bui^H^H^Hsend such message, and that's
easily solvable, by either dropping the connection between state names
and meaning, or by dopping the disjointness of states.

What do you prefer? 


> > Already now there are tasks that get prioritized, and assigned, and
> > re-prioritized, re-assigned, "Fix-for-version"-ed, closed, re-opened
> > several times. Watchers that e.g. wait for a "Done" there get notified
> > each time on such unprogressing transitions, and skipping these sums
> > up to quite a bit of unproductive time already now.
> 
> True enough; this would introduce one more transition, so one more
> e-mail per bug.  None the less, it's a transition that does mean
> something useful to those watching - especially those waiting for a fix
> - we are a significant step closer to a fix,

Is is?

First, being on review might still not mean getting closer to 'Done'.
Patches get rejected or delayed for real or imagined reasons, nobody
might actually review, a successful review might not be convincing
enough for CI to let it pass etc, etc.

Second, water-level reports on how close something is to being done
is practically never the reason why I watch tasks, I watch them 
because I may need to act once it is resolved. And only then.

> and there's a patch they might even be interested in applying
> locally.  And, as Lorn pointed out, issues don't have to go through
> every stage; it'd just be there for the benefit of those who find it
> useful.

And to the distraction to those that don't. That's why the 'Verified'
state was removed not that long ago.
 
> Yes, we could do that with a tag, although I'm not sure how well Jira's
> "scrum board" view would integrate with that.  In any case, adding such
> tags would generate mail, just as state transitions would, and
> cluttering Jira with a plethora of person-specific and team-specific
> tags

We have "Reported_by_X", "Y_thinks_this_is_a_P1", "up", "Earmarked_by_Z",
and a lot more. And it's completely fine to have them. The rule to
handle them is easy: "If you are not fully convinced it is meant for you
it /is/ not meant for you".

> might not be the clearest way to communicate with folk; in
> particular it'd mean there's no uniform way for teams to communicate
> this, making it harder to write tools that can be shared between teams
> with similar work-flows.

Can't comment here, as I don't know what kind of tools this refers to.

> > Looks like we are getting to the actual problem here. It's not
> > about development after all.
> 
> No "getting to" about it - my original mail was quite explicit about
> the point of the exercise being clarity of communication with my
> scrum master (whose beard is plaited - I would not call his hair
> pointy).

I am positive an "Eddy-calls-this-Done" label will be explicit enough
to communicate the fact that Eddy calls this "Done" within this
particular relation.

> We've had tasks where the actual coding was done in one sprint but
> the review and integration (and waiting for merges up from one branch
> to another) have happened in other sprints. Distinguishing those
> parts of the work would make sprint organisation easier.

Ok, more seriously: I think you want to communicate "I did what I can
do here, for this period of time". This is a valid, and noteworthy
state, but at the same time orthogonal to the existing JIRA states. It
would also apply to an "Won't do", or "Invalid", or whatever else state
you chose after working on the issue. This calls for some markup that 
is orthogonal to existing JIRA states, and a label provides that.

> The co-ordination of development, and communication to stake-holders
> of what's going on, are important parts of our process. To dismiss
> them out of hand as "not about development" strikes me as painfully
> limiting.  Jira is a tool as much for our customers (reporting bugs
> and getting feed-back on whether and when we're going to do anything
> about them) and our managers as for us. 

[ . o O ( BINGO! ) ...  ]

> The addition of an "In Review" state would mak

Re: [Development] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW

[Cristian Adam]

> > > Judging from the screenshots, it's the latest and greatest version
> > > of the Qt installer (qt-opensource-windows-x86-5.14.1.exe) [1]
> >
> > Okay, but what version of Qt is the Qt Installer using? Installer
> > team, can you check?
> >
> 
> Looking into the binary I've found:
> 
> "Build date: Jan  8 2020 IFW Version: 3.2.0, built with Qt 5.12.4."
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/272837 Fix
> QRandomGenerator initialization on AMD CPUs
> 
> fixed it for 5.13 and a there we can see a cherry pick for 5.12:
> https://codereview.qt-project.org/c/qt/qtbase/+/275914
> which went in on 9th of October 2019.
> 
> Qt 5.12.4 was released on 17th of June 2019.
> Qt 5.12.6 was released on 13th of November 2019, and should have the fix.
> 
> Installer needs to use an more up to date Qt.
> 

I've opened up a ticket for the Qt Installer Framework:
https://bugreports.qt.io/browse/QTIFW-1632

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW

[Cristian Adam]

> >
> > Judging from the screenshots, it's the latest and greatest version of
> > the Qt installer (qt-opensource-windows-x86-5.14.1.exe) [1]
> 
> Okay, but what version of Qt is the Qt Installer using? Installer team, can 
> you
> check?
> 

Looking into the binary I've found:

"Build date: Jan  8 2020 IFW Version: 3.2.0, built with Qt 5.12.4."

https://codereview.qt-project.org/c/qt/qtbase/+/272837 Fix QRandomGenerator 
initialization on AMD CPUs 

fixed it for 5.13 and a there we can see a cherry pick for 5.12:
https://codereview.qt-project.org/c/qt/qtbase/+/275914
which went in on 9th of October 2019.

Qt 5.12.4 was released on 17th of June 2019.
Qt 5.12.6 was released on 13th of November 2019, and should have the fix.

Installer needs to use an more up to date Qt.

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW

[Boudewijn Rempt via Development]

On woensdag 19 februari 2020 00:51:12 CET Thiago Macieira wrote:

> Also https://bugreports.qt.io/browse/QTBUG-70606, which is when I reported 
> the 
> problem to AMD, but we did not introduce a workaround since we didn't know it 
> was this widespread.

We for sure encountered it very, very often with our Krita users, until Dmitry 
patched it: https://codereview.qt-project.org/c/qt/qtbase/+/272837. 

-- 
https://www.valdyas.org | https://www.krita.org


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW

[Konstantin Ritt]

Just for clarity: systemd has worked around this issue back in 2019 IIRC ,
once the issue has been widely reported and confirmed. Did that allow the
user to boot his linux? Yes, the user is now able to boot into his shiny
and fast (yet insecure and highly vulnerable) operation system. Months
later, do we (Qt) REALLY have to be the only "secure" citizen in the
0x world? If so, then what about ASLR, SSP and other techniques
aimed to protect your lovely lib/app/os from ACE but can not (due to broken
HW RNG, which the user could never know about)?!


Regards,
Konstantin


ср, 19 февр. 2020 г. в 18:26, Konstantin Ritt :

> Should we ever try to work around issues caused by broken CPUs? Maybe we
> should warn the user instead (with big red banner) and decline to install
> anything at all?
>
> >  (or buy Intel)
>
> Or let's maybe also try to work around Meltdown and Spectre on i, just for
> symmetry? ;)
>
> Regards,
> Konstantin
>
>
> ср, 19 февр. 2020 г. в 01:51, Thiago Macieira :
>
>> On Tuesday, 18 February 2020 05:36:56 PST Sze Howe Koh wrote:
>> > > Christian Kandeler (18 February 2020 12:59) replied
>> > >
>> > > > Probably the same as https://bugreports.qt.io/browse/QTBUG-77375.
>>
>> Also https://bugreports.qt.io/browse/QTBUG-70606, which is when I
>> reported the
>> problem to AMD, but we did not introduce a workaround since we didn't
>> know it
>> was this widespread.
>>
>> > > Which version was this encountered in ?
>> > >
>> >
>> > Judging from the screenshots, it's the latest and greatest version of
>> > the Qt installer (qt-opensource-windows-x86-5.14.1.exe) [1]
>>
>> Okay, but what version of Qt is the Qt Installer using? Installer team,
>> can
>> you check?
>>
>> Also, anyone affected, PLEASE upgrade your BIOS right now. Your system is
>> insecure. (or buy Intel)
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel System Software Products
>>
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW

[Konstantin Ritt]

Should we ever try to work around issues caused by broken CPUs? Maybe we
should warn the user instead (with big red banner) and decline to install
anything at all?

>  (or buy Intel)

Or let's maybe also try to work around Meltdown and Spectre on i, just for
symmetry? ;)

Regards,
Konstantin


ср, 19 февр. 2020 г. в 01:51, Thiago Macieira :

> On Tuesday, 18 February 2020 05:36:56 PST Sze Howe Koh wrote:
> > > Christian Kandeler (18 February 2020 12:59) replied
> > >
> > > > Probably the same as https://bugreports.qt.io/browse/QTBUG-77375.
>
> Also https://bugreports.qt.io/browse/QTBUG-70606, which is when I
> reported the
> problem to AMD, but we did not introduce a workaround since we didn't know
> it
> was this widespread.
>
> > > Which version was this encountered in ?
> > >
> >
> > Judging from the screenshots, it's the latest and greatest version of
> > the Qt installer (qt-opensource-windows-x86-5.14.1.exe) [1]
>
> Okay, but what version of Qt is the Qt Installer using? Installer team,
> can
> you check?
>
> Also, anyone affected, PLEASE upgrade your BIOS right now. Your system is
> insecure. (or buy Intel)
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: more Jira states to track stages of the work on an issue

[Volker Hilsheimer]

> On 19 Feb 2020, at 10:45, Edward Welbourne  wrote:
> 
 What's the harm in leaving the task in In Progress state while it's being
 reviewed?
>>> 
>>> There is no harm, but being able to better distinguish the main development
>>> phase of a large task from the review stage would benefit the 'pointy hairs'
>>> [...]
> 
>> Looks like we are getting to the actual problem here. It's not about
>> development after all.
> 
> No "getting to" about it - my original mail was quite explicit about the
> point of the exercise being clarity of communication with my scrum
> master (whose beard is plaited - I would not call his hair pointy).
> 
> We've had tasks where the actual coding was done in one sprint but the
> review and integration (and waiting for merges up from one branch to
> another) have happened in other sprints.  Distinguishing those parts of
> the work would make sprint organisation easier.
> 
> The co-ordination of development, and communication to stake-holders of
> what's going on, are important parts of our process.  To dismiss them
> out of hand as "not about development" strikes me as painfully limiting.
> Jira is a tool as much for our customers (reporting bugs and getting
> feed-back on whether and when we're going to do anything about them) and
> our managers as for us.  The addition of an "In Review" state would make
> it easier for me to communicate, to everyone with an interest in my
> work, something that at least two of them have made clear they want to
> know (and that I have commonly wanted to communicate).
> I naively imagine other teams have similar needs.
> 
> I'm proposing a uniform way to do that, for those teams that want it.


Even when doing development (as opposed to the pointy-haired work), I benefit 
from having tools that help me to maintain a work-in-progress limit, that allow 
me to see what state the work someone else is doing is in (because I might 
depend on it or just be curios about it), or allow me to signal to customers 
waiting for the fix that they might want to have a look at a proposed change, 
even if they don't have an account on Gerrit.

The Qt Project defines “code review” as an explicit step that contributions 
have to go through. Given that it takes a substantial amount of time to get 
things through review, I think it would make the JIRA-model of how work happens 
a bit more useful if it would reflect the way that work actually happens.

So, I support introducing this as an optional state.

Cheers,
Volker


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: more Jira states to track stages of the work on an issue

[Edward Welbourne]

On Tue, Feb 18, 2020 at 01:11:29PM +1000, Lorn Potter wrote:
>> Stepping through the interim steps is not a requirement, so it is not that
>> much difference to go from Reported->In Progress to Reported->In Review,
>> really.
>>
>> So the list you have to select from has one more entry to choose from, is
>> that such a big deal?

André Pönitz (18 February 2020 20:39)
> This is not the problem.
>
> More states lead to bikeshedding what would be The Right State for a
> task.

I very much doubt the distinction between In Progress and In Review is
going to involve much bike-shedding.

> Already now there are tasks that get prioritized, and assigned, and
> re-prioritized, re-assigned, "Fix-for-version"-ed, closed, re-opened
> several times. Watchers that e.g. wait for a "Done" there get notified
> each time on such unprogressing transitions, and skipping these sums
> up to quite a bit of unproductive time already now.

True enough; this would introduce one more transition, so one more
e-mail per bug.  None the less, it's a transition that does mean
something useful to those watching - especially those waiting for a fix
- we are a significant step closer to a fix, and there's a patch they
might even be interested in applying locally.  And, as Lorn pointed out,
issues don't have to go through every stage; it'd just be there for the
benefit of those who find it useful.

Yes, we could do that with a tag, although I'm not sure how well Jira's
"scrum board" view would integrate with that.  In any case, adding such
tags would generate mail, just as state transitions would, and
cluttering Jira with a plethora of person-specific and team-specific
tags might not be the clearest way to communicate with folk; in
particular, it'd mean there's no uniform way for teams to communicate
this, making it harder to write tools that can be shared between teams
with similar work-flows.

>> > What's the harm in leaving the task in In Progress state while it's being
>> > reviewed?
>>
>> There is no harm, but being able to better distinguish the main development
>> phase of a large task from the review stage would benefit the 'pointy hairs'
>> [...]

> Looks like we are getting to the actual problem here. It's not about
> development after all.

No "getting to" about it - my original mail was quite explicit about the
point of the exercise being clarity of communication with my scrum
master (whose beard is plaited - I would not call his hair pointy).

We've had tasks where the actual coding was done in one sprint but the
review and integration (and waiting for merges up from one branch to
another) have happened in other sprints.  Distinguishing those parts of
the work would make sprint organisation easier.

The co-ordination of development, and communication to stake-holders of
what's going on, are important parts of our process.  To dismiss them
out of hand as "not about development" strikes me as painfully limiting.
Jira is a tool as much for our customers (reporting bugs and getting
feed-back on whether and when we're going to do anything about them) and
our managers as for us.  The addition of an "In Review" state would make
it easier for me to communicate, to everyone with an interest in my
work, something that at least two of them have made clear they want to
know (and that I have commonly wanted to communicate).
I naively imagine other teams have similar needs.

I'm proposing a uniform way to do that, for those teams that want it.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] QtLocation / QtPositioning and Web Assembly

[Sebastian Kügler]

Hi,

I'd like to create an application using the MapView QtQuick plugin and deploy 
that application using the Web Assembly platform. It seems, though, that the 
QtPositioning and QtLocation modules are not (yet?) available for WASM.

- Did anybody already get it to work?
- Is this planned by anybody?
- What would be the steps / likely time investment, etc. to be able to use 
these modules in a WASM-deployed application?

Thanks in advance,
-- 
sebas

http://www.kde.org | http://vizZzion.org


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development