Re: [Development] automated bulk change closing old issues in the "Need more info" state
> On 20 Nov 2018, at 08:14, Uwe Rathmann wrote: > > F.e the QPA/EGLFS stuff is full of problems, when working with multiple > touch screens. But obviously this is a rare combination and the Qt > Company seems not being interested - or lost the competence - in fixing > it. I’m interested in having it work some day, because the inconvenient means of configuring that (by writing JSON files ahead of time) is holding up one of my spare-time projects. But, I’m interested in too many things, and also don’t know exactly what to do about that issue right now, since I’m lacking some experience that others have with trying to support specific embedded systems. I think ideally it should be auto-configured somehow when possible. That might involve a database of known touchscreen monitors, but we should get that from a third party, not maintain it (just like there are databases with EDID info, USB IDs, PCI IDs and such things). Maybe it already exists? But there also needs to be API for dynamically configuring the screen-to-touchscreen mapping, and saving and restoring known-good configurations when the auto-configuration goes wrong. Since QTouchDevice is public and does not inherit from any common device class, I figure getting the API right is a Qt 6 task. I want to have a device hierarchy so that devices in general can be associated with each other (associating screens and touch input devices is just one case, but probably there will be others). Presumably the Plasma project has the same problems with wanting to dynamically configure hotplugged screens (some of which might be touchscreens). I don’t even know the status… since Plasma on Wayland is still unstable even now, AFAICT. (I wouldn’t be surprised if that’s our fault too.) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] automated bulk change closing old issues in the "Need more info" state
-Original Message- > From: Development project.org> On Behalf Of Shawn Rutledge > https://bugreports.qt.io/issues/?filter=16028 currently has 169 bugs in that > state. Having that many is an obstacle: I don’t suppose this week’s triage > team > is going to get through all of those and make intelligent decisions about > them, > either. If it was only 10, maybe they would. This filter is limited in scope. It considers only tasks which have been updated within the last 14 days. Naturally this causes bugs to drop out over time. I don't think this is a problem once the automation is enabled. Note that the level of NMI issues was 2.5k at the end of September before I dropped it to ~700 (nothing older than 1 year since update). This round halfed the number again. The remainder is no older than 20wks. This is was I intend as seed for the automation. Note that I am on watch on all those issues. People just have to comment with reasonable explanation and I reopen. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] automated bulk change closing old issues in the "Need more info" state
> -Original Message- > From: Development project.org> On Behalf Of André Pönitz ... > A possible solution would be some automated state transition off "Need more > info" once any comment had been added. At least that is a good first > approximation that is more often right than wrong. And maybe "Need more > info" should be used only when running into actual trouble when reproducing a > bug, not as first line of defense for any bug. One could e.g. ask for more > potentially useful but not exactly necessary info without setting "Need more > info". That's exactly what's going to happen. This was discussed and agreed upon on this mailing list a while ago. This round of closures was done in preparation of this change. I just wanted to bring the number of issues stuck in NMI down to the not-to-ancient ones and fix the surrounding documentation before I enable the automation later this week. Time limits will be 2 wks for first reminder and after 2 more wks the bug will be closed. A comment from anybody but the assignee will trigger the automatic return of the task from NMI to "Reported". https://wiki.qt.io/Jira_Automation -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] automated bulk change closing old issues in the "Need more info" state
On Mon, 19 Nov 2018 20:00:30 +, Volker Hilsheimer wrote: > I understand that the “need more info” -> auto-closing bot workflow is > to some degree a bit of a probe to see if someone still cares. A bug is a bug and if the one who has reported it has lost the interest in it months/years later - usually because not working on the project anymore - should not matter. But maybe the mentality of a commercial product is different than mine. > When do you consider a bug report “lost”? When bug report does not end with a conscious decision of a developer. > So, leaving it in a “I’ll fix this when I get to it” kind of > state is rather not helpful. If the state would be true, I don't have a problem with it. But I can't remember any bug report, that ever left this state after being there for longer than - let's say 2 weeks. Actually I already stopped reporting bugs in areas, where you end up with assignees, that are known as a pseudonym for /dev/null. F.e the QPA/EGLFS stuff is full of problems, when working with multiple touch screens. But obviously this is a rare combination and the Qt Company seems not being interested - or lost the competence - in fixing it. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] automated bulk change closing old issues in the "Need more info" state
> On 19 Nov 2018, at 16:09, Uwe Rathmann wrote: > I guess my bugs are not the only ones and if you don't want to lose a lot > of valuable reports this way better stop an revert this bulk changes. I understand that the “need more info” -> auto-closing bot workflow is to some degree a bit of a probe to see if someone still cares. It certainly isn’t a greatly named state for that purpose (and one should expect a comment when a bug is moved to that state), but that aside, I’m curious: When do you consider a bug report “lost”? JIRA doesn’t forget the bug report. It’s still there, will show up in your searches for “stuff I reported and that wasn’t fixed”, and you get notified when something changes. Perhaps it gets closed as “won’t do” or some other not-fixed resolution because the assignee or maintainer or The Qt Company decides that they are not going to fix the issue (for whatever reason; "corner case”; "too risky to change the code”; “not something we will ever prioritise”). For a bug report that’s been open for a long time, probability that it results in real action is perhaps going down rather than up the longer you wait. So, leaving it in a “I’ll fix this when I get to it” kind of state is rather not helpful. When it’s closed as “won’t do” etc, at least you know what to expect, and that it’s probably going to be worth your time to develop a workaround or dig into the code yourself to see if you can come up with a fix. Cheers, Volker ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] automated bulk change closing old issues in the "Need more info" state
On Mon, Nov 19, 2018 at 04:36:45PM +, Shawn Rutledge wrote: > [...] > I suspect the reason people don’t hit that button is that it’s at the > top, whereas when you add a normal comment, you press the comment > button at the bottom. And if you are actually answering the question > with your comment, you assume that’s enough, right? Right. Having to press that button is completely unintuitive for a reporter, especially after one has been told to not overstep one's competences by e.g. change priorities of bugs. > So maybe that button should be (repeated?) at the bottom left. > But I doubt we can customize our Jira to that extent. A possible solution would be some automated state transition off "Need more info" once any comment had been added. At least that is a good first approximation that is more often right than wrong. And maybe "Need more info" should be used only when running into actual trouble when reproducing a bug, not as first line of defense for any bug. One could e.g. ask for more potentially useful but not exactly necessary info without setting "Need more info". Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] automated bulk change closing old issues in the "Need more info" state
On Mon, 19 Nov 2018 16:01:32 + Kai Koehne wrote: > > -Original Message- > > From: Development > project.org> On Behalf Of Uwe Rathmann > > Sent: Monday, November 19, 2018 4:10 PM > > To: development@qt-project.org > > Subject: [Development] automated bulk change closing old issues in the "Need > > more info" state > > > > Hi all, > > > > I just received 2 messages about: automated bulk change closing old issues > > in > > the "Need more info" state. > > > > - https://bugreports.qt.io/browse/QTBUG-68874 > > - https://bugreports.qt.io/browse/QTBUG-66264 > > > > I have no idea why they have been set to "Need more info" - actually one of > > them has been explicitly answered, but the developer does not follow up. > > Then it's good that the bot pointed the wrong state out. Please move the bugs > back to open state (as you apparently did already). Next time you answer, > consider clicking "Provide missing info", instead of just commenting [1]. The fact that this is not done ~90% of the time indicates a UI/workflow problem, does it not? Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] automated bulk change closing old issues in the "Need more info" state
On Mon, 19 Nov 2018 16:36:45 +, Shawn Rutledge wrote: > Also, every week we have a team of 2 people triaging bugs. Part of that > job is to check all the bugs that are in “need more info” state, and > decide whether the info is now sufficient. In the case of my bugs: in one of them it is totally unclear what additional info is required or who is the one who should provide more info. The only thing that seems to be clear is that it is not me, who is asked. In the other case setting the "need more info" state looked more like playing ping pong with the reporter ( = me ). Nevertheless I tried my best to answer, but was not aware of having to hit an extra button. But both bug reports have at least been looked at. I have others with much higher importance, that have been prioritized and assigned once and then - silence forever. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] automated bulk change closing old issues in the "Need more info" state
Den mån 19 nov. 2018 kl 17:36 skrev Shawn Rutledge : > > > > On 19 Nov 2018, at 16:09, Uwe Rathmann wrote: > > > > Hi all, > > > > I just received 2 messages about: automated bulk change closing old > > issues in the "Need more info" state. > > > > - https://bugreports.qt.io/browse/QTBUG-68874 > > - https://bugreports.qt.io/browse/QTBUG-66264 > > > > I have no idea why they have been set to "Need more info" - actually one > > of them has been explicitly answered, but the developer does not follow > > up. > > When you answer the question, you are supposed to hit the “provide missing > info” button: that takes it out of that state. > > Also, every week we have a team of 2 people triaging bugs. Part of that job > is to check all the bugs that are in “need more info” state, and decide > whether the info is now sufficient. Then it should either be moved out of > “need more info” state, or closed. But it’s easy to ignore that… so I > suspect many triage teams aren’t trying very hard to get through those. > Often, the reporter of the bug does not provide any extra info for a long > period of time, so it is demotivating to go through the list and just confirm > yet again that nothing new was added to most of them. > > https://bugreports.qt.io/issues/?filter=16028 currently has 169 bugs in that > state. Having that many is an obstacle: I don’t suppose this week’s triage > team is going to get through all of those and make intelligent decisions > about them, either. If it was only 10, maybe they would. > > So to shorten that list, it helps a lot if you hit the “provide missing info” > button when you answer a question. If the bug does not have a priority > and/or is unassigned, then it’s going to get looked at again by that week’s > triage team. If it stays in “need more info” state, it might be ignored for > a while because it’s not in the un-triaged list. Not ideal, but that’s how > it’s actually been. > > I suspect the reason people don’t hit that button is that it’s at the top, > whereas when you add a normal comment, you press the comment button at the > bottom. And if you are actually answering the question with your comment, > you assume that’s enough, right? So maybe that button should be (repeated?) > at the bottom left. But I doubt we can customize our Jira to that extent. Maybe some standard reminder about the "Provide Missing Info" button could be added when the issue is first put into "Need More Info" state? If the info is there as part of the normal comment flow, the one making the followup comment with more info would see it I think (Not sure to what extent that could be automated though). Elvis > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] automated bulk change closing old issues in the "Need more info" state
> On 19 Nov 2018, at 16:09, Uwe Rathmann wrote: > > Hi all, > > I just received 2 messages about: automated bulk change closing old > issues in the "Need more info" state. > > - https://bugreports.qt.io/browse/QTBUG-68874 > - https://bugreports.qt.io/browse/QTBUG-66264 > > I have no idea why they have been set to "Need more info" - actually one > of them has been explicitly answered, but the developer does not follow > up. When you answer the question, you are supposed to hit the “provide missing info” button: that takes it out of that state. Also, every week we have a team of 2 people triaging bugs. Part of that job is to check all the bugs that are in “need more info” state, and decide whether the info is now sufficient. Then it should either be moved out of “need more info” state, or closed. But it’s easy to ignore that… so I suspect many triage teams aren’t trying very hard to get through those. Often, the reporter of the bug does not provide any extra info for a long period of time, so it is demotivating to go through the list and just confirm yet again that nothing new was added to most of them. https://bugreports.qt.io/issues/?filter=16028 currently has 169 bugs in that state. Having that many is an obstacle: I don’t suppose this week’s triage team is going to get through all of those and make intelligent decisions about them, either. If it was only 10, maybe they would. So to shorten that list, it helps a lot if you hit the “provide missing info” button when you answer a question. If the bug does not have a priority and/or is unassigned, then it’s going to get looked at again by that week’s triage team. If it stays in “need more info” state, it might be ignored for a while because it’s not in the un-triaged list. Not ideal, but that’s how it’s actually been. I suspect the reason people don’t hit that button is that it’s at the top, whereas when you add a normal comment, you press the comment button at the bottom. And if you are actually answering the question with your comment, you assume that’s enough, right? So maybe that button should be (repeated?) at the bottom left. But I doubt we can customize our Jira to that extent. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] automated bulk change closing old issues in the "Need more info" state
> -Original Message- > From: Development project.org> On Behalf Of Uwe Rathmann > Sent: Monday, November 19, 2018 4:10 PM > To: development@qt-project.org > Subject: [Development] automated bulk change closing old issues in the "Need > more info" state > > Hi all, > > I just received 2 messages about: automated bulk change closing old issues in > the "Need more info" state. > > - https://bugreports.qt.io/browse/QTBUG-68874 > - https://bugreports.qt.io/browse/QTBUG-66264 > > I have no idea why they have been set to "Need more info" - actually one of > them has been explicitly answered, but the developer does not follow up. Then it's good that the bot pointed the wrong state out. Please move the bugs back to open state (as you apparently did already). Next time you answer, consider clicking "Provide missing info", instead of just commenting [1]. > ( There might be other good reasons closing these bugs, but waiting for more > info is definitely not the case ) > > I guess my bugs are not the only ones and if you don't want to lose a lot of > valuable reports this way better stop an revert this bulk changes. > > Why should anyone continue reporting bugs, when all what happens is, that > they are put on hold and finally closed automatically ? Don't shoot the messenger Your bugs where in a 'need more info' state, which a lot of searches exclude, and might have therefore gotten less attention. If you have a bug in the 'Need more info" state and it's unclear to you what information is missing, just ask. Kai [1]: I agree that the workflow is suboptimal there, but that's apparently what JIRA offers. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] automated bulk change closing old issues in the "Need more info" state
Hi all, I just received 2 messages about: automated bulk change closing old issues in the "Need more info" state. - https://bugreports.qt.io/browse/QTBUG-68874 - https://bugreports.qt.io/browse/QTBUG-66264 I have no idea why they have been set to "Need more info" - actually one of them has been explicitly answered, but the developer does not follow up. ( There might be other good reasons closing these bugs, but waiting for more info is definitely not the case ) I guess my bugs are not the only ones and if you don't want to lose a lot of valuable reports this way better stop an revert this bulk changes. Why should anyone continue reporting bugs, when all what happens is, that they are put on hold and finally closed automatically ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
