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
[Development] Why Coin?
Hi all, I’ve been from time to time getting questions around Coin, and why we started developing our own CI system for Qt instead of using some available solution. To understand it, we will probably need to go back a few years to the time when we started developing it. At that point in time, we had a Jenkins based CI system that was giving us quite a few problems. Amongst them were * We had lots of stability issues with the system. Much later, we saw that some of those issues were problems in the networking and virtualisation layer, but we didn’t know this at that time. * CI machines were constantly running, making it very hard to balance resource requirements and leading to rather bad hardware utilisation. * The long running CI machines could easily accumulate a lot of garbage (again leading to instabilities and hard to debug problems) * We could only ever do one release at a time, as switching branches required us to switch the VM templates * We couldn’t deal with modularised repositories in a decent way, so we always had to compile all dependencies from scratch leading to extremely long turn around times * The branch configurations were managed by hand, sometimes leading to problems when creating new branches * CI and packaging were disconnected, so we had to compile everything once again from scratch to create binary packages (with slightly different configurations). This often lead to build errors during packaging that weren’t visible in CI. In addition, this wasted a lot of time and resources. We had a minimum turn around time from a fix being staged on Gerrit until it ended up in the package of 48 hours. * Lack of provisioned build/test VMs. * Developers couldn’t access the build/test VMs themselves for debugging (now we can at least provide it to people working at TQtC) * We didn’t have any tests for the CI system itself, making it difficult to change and maintain. * There were probably other issues that I’ve forgotten about now… So we did sit down some years ago trying to find out how to best solve those problems. We did look at a variety of different solutions that existed and whether they could solve the problems we were having. In the end we came to the conclusion that none of the solutions that existed at that point in time were what we really needed and wanted. That left us with the option of either implementing a lot of new functionality for an existing system or doing our own solution. We ended up going for our own, as we couldn’t see how to easily bring the existing solutions to where we wanted them to be. That turned out to be a larger effort than we initially estimated. Nevertheless, Coin is nowadays a much better system than what we had some years ago with Jenkins. Most of the problems mentioned above are solved today. So where are we with Coin today? Let’s have a quick overview over what we have and maybe also the remaining issues we’re seeing: The CI system contains several layers. As the basis, we have a cluster of rather powerful blades and a large set of Macs. Those are running inside a separate DMZ inside the Qt Company’s network. Each of those blades runs Linux with KVM as the hypervisor. The whole cluster is administered through OpenNebula/MAAS. Coin itself runs on a separate powerful machine and brings up VMs as needed through OpenNebula. It listens to staging requests from Gerrit and contains all the logic to determine how and on which platforms to test a set of changes (the list of platforms and how they are provisioned is stored in qt5.git). In addition, it has a large storage area where we cache generated binary artifacts for the different repositories/branches/sha1s. Those are being used to test changes in dependent repositories, so we don’t need to compile qtbase every time. In addition, the binary artefacts are also being used for the creation of our binary packages. But as you know, it’s certainly not perfect, and we have our regular share of bugs and problems with the system. Coin itself is actually running pretty nicely and doesn’t generate too many problems. We have decent control over it, and most bugs that we notice in the Coin codebase itself are not too hard to fix. There are however a couple of other issues that are still creating problems for us: * The network was causing lots of problems, we were seeing random packets being dropped and random disconnects of TCP connections. We have done some changes here last week, and are optimistic that this has now been fixed * Windows 10 VMs are sometimes extremely slow when being run on top of our current host Linux/KVM combination. The root cause has still not been fully identified, but we are currently working on upgrading the host OS to a newer Ubuntu version. Judging from similar bug reports by others, there’s a good chance that this will resolve the problem. * Flaky tests are a recurring problems. We’ve spend a lot of time trying to identify them an
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] Resolving coding style contentions
On Mon, 19 Nov 2018 at 22:41, Thiago Macieira wrote: > > On Monday, 19 November 2018 12:03:06 PST Ville Voutilainen wrote: > > I personally tend to split such things after an opening parenthesis. > > Getting back to allowing ctor-initializers to be written > > with a comma starting a line, I think we should just allow it; the > > benefit of not having noise in a diff seems to outweigh > > the minor aesthetics of it. > > It is allowed, unless the maintainer objects to it. > > I object to it in QtCore. I'm suggesting that you stop objecting to it. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Resolving coding style contentions
On Monday, 19 November 2018 12:41:46 PST Thiago Macieira wrote:
> It is allowed, unless the maintainer objects to it.
>
> I object to it in QtCore.
I also insist that the opening brace in non-nested classes, enums and in any
functions be placed in a new line (unless the entire function is in one line)
bool X::foo() { return m_value; } // ok
class Foo { // not ok
public:
bool foo() const { // not ok
return m_value;
}
};
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt6/Qt5 coinstallability (Linux distributions)
On Monday, 19 November 2018 11:42:48 PST Lisandro Damián Nicanor Pérez Meyer wrote: > b) If at some point we can agree it has been decided, is there any way I > could start contributing code in order to achieve this? Maybe I should just > wait until the new build system is on stage? something else? Since it's a Qt 6 thing, it should happen with the buildsystem, which means we need to actually decide on which one to use. Even though it currently looks there's only one in contention, it's not a *decision*. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Resolving coding style contentions
On Monday, 19 November 2018 12:03:06 PST Ville Voutilainen wrote: > I personally tend to split such things after an opening parenthesis. > Getting back to allowing ctor-initializers to be written > with a comma starting a line, I think we should just allow it; the > benefit of not having noise in a diff seems to outweigh > the minor aesthetics of it. It is allowed, unless the maintainer objects to it. I object to it in QtCore. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 6 and standard types
On Monday, 19 November 2018 12:06:30 PST Volker Hilsheimer wrote: > > On 17 Nov 2018, at 22:18, Thiago Macieira > > wrote: > > On Saturday, 17 November 2018 12:58:10 PST Bernhard Lindner wrote: > > > >> Hi everybody! > >> > >> Are there any plans for Qt6' API to use standard types like size_t (or > >> special replacements like qsizetype) for return values and parameters > >> that > >> have platform dependent width? > > > > > > Yes. See the thread "Another integer typedef OR how to prepare for 64-bit > > in Qt 5” > > > Are those discussions, once they have resulted in a conclusion/decision, > turned into wiki pages or design documents or something? They should be turned into QUIPs, if relevant. > Archived email threads are not a great way of capturing knowledge, which is > not helped by the somewhat archaic search capabilities of the mailman UI. I know. Anyway: https://codereview.qt-project.org/246012 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 6 and standard types
> On 17 Nov 2018, at 22:18, Thiago Macieira wrote: > > On Saturday, 17 November 2018 12:58:10 PST Bernhard Lindner wrote: >> Hi everybody! >> >> Are there any plans for Qt6' API to use standard types like size_t (or >> special replacements like qsizetype) for return values and parameters that >> have platform dependent width? > > Yes. See the thread "Another integer typedef OR how to prepare for 64-bit in > Qt 5” Are those discussions, once they have resulted in a conclusion/decision, turned into wiki pages or design documents or something? Archived email threads are not a great way of capturing knowledge, which is not helped by the somewhat archaic search capabilities of the mailman UI. Cheers, Volker ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Resolving coding style contentions
On Mon, 19 Nov 2018 at 18:37, Thiago Macieira wrote:
>
> On Monday, 19 November 2018 02:34:09 PST Edward Welbourne wrote:
> > I note a glaring exception to that: after the opening parenthesis of
> > a parameter list, if the line would otherwise be too long:
> >
> > auto variable =
> > QCharacteristicallyVerboseClassName::characteristicallyLongFunctionName(
> > firstParameter, secondParameter, thirdParameter, fourthParameter);
> >
> > is tolerated (well, maybe not the naming ...), but a space *without*
> > the line-break between open-paren and firstParameter is forbidden.
>
> Right, when your line would be too long, you need to break *somewhere*. Take
> this example of a long sequence with no spacing:
>
>
> QObject::tr("%1%2%3%4").arg(someFunction()).arg(otherFunction()).arg(thirdFunction()).arg(lookMaNoSpaces());
>
> This has no space at all, so much that not even the email composer can break
> it anywhere.
>
> In this case, it's often that we break before the dot, so the next line starts
> with punctuation.
I personally tend to split such things after an opening parenthesis.
Getting back to allowing ctor-initializers to be written
with a comma starting a line, I think we should just allow it; the
benefit of not having noise in a diff seems to outweigh
the minor aesthetics of it.
___
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] Qt6/Qt5 coinstallability (Linux distributions)
El martes, 13 de noviembre de 2018 23:58:28 -03 Thiago Macieira escribió: > On Tuesday, 13 November 2018 18:43:03 PST Kevin Kofler wrote: [snip] > > I think it would be much safer to just version everything. > > > > Just remember Assistant in Qt 4, where early 4.x releases shipped an > > Assistant that was essentially compatible with the Qt 3 version, but it > > was > > later renamed to assistant_adp (and later dropped from the Qt distribution > > and shipped as an unmaintained separate legacy tarball) and a new > > incompatible Assistant (the QCH one) was introduced. > > Ok, so two categories only: > 1) applications run by the user (in bin, versioned) > 2) applications run only during build (in libexec, unversioned) I would of course agree here. But so far only three of us participated in this thread, so I would like to ask: a) Is there something else I could do to make this a consensus decision? Or maybe do something to make this the roadmap for Qt 6? b) If at some point we can agree it has been decided, is there any way I could start contributing code in order to achieve this? Maybe I should just wait until the new build system is on stage? something else? Cheers, Lisandro. -- When the winds of change are blowing, some people are building shelters, and others are building windmills. Old Chinese Proverb Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ 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] Resolving coding style contentions
On Monday, 19 November 2018 02:34:09 PST Edward Welbourne wrote:
> I note a glaring exception to that: after the opening parenthesis of
> a parameter list, if the line would otherwise be too long:
>
> auto variable =
> QCharacteristicallyVerboseClassName::characteristicallyLongFunctionName(
> firstParameter, secondParameter, thirdParameter, fourthParameter);
>
> is tolerated (well, maybe not the naming ...), but a space *without*
> the line-break between open-paren and firstParameter is forbidden.
Right, when your line would be too long, you need to break *somewhere*. Take
this example of a long sequence with no spacing:
QObject::tr("%1%2%3%4").arg(someFunction()).arg(otherFunction()).arg(thirdFunction()).arg(lookMaNoSpaces());
This has no space at all, so much that not even the email composer can break
it anywhere.
In this case, it's often that we break before the dot, so the next line starts
with punctuation.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
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
Re: [Development] Resolving coding style contentions
On Sunday, 18 November 2018 05:30:26 PST Sze Howe Koh wrote: >> I'd just like to know: Did the Qt Project ever reach a decision? If not, >> how can we reach one? (Linked to the discussion of constructor initializers like MyClass(type param) : MyBase(param) , myMember(param) using comma at start of line, for anyone who hasn't followed the link.) Thiago Macieira (18 November 2018 20:49) replied > I don't think we did. Right now, it's up to the maintainer's discretion. My (highly unreliable) memory concurs. > QtCore opts into the rule: newlines are whitespace. (I wonder if we'll ever get round to renaming that character class "spacing characters" - I've been using blackspace in my reverse-video emacs windows for a quarter century now; and, before that, I used quite a lot of greenspace. But web-browsers insist on it being white.) > Corollary: you can only insert a newline where a space is allowed by the > coding convention. I note a glaring exception to that: after the opening parenthesis of a parameter list, if the line would otherwise be too long: auto variable = QCharacteristicallyVerboseClassName::characteristicallyLongFunctionName( firstParameter, secondParameter, thirdParameter, fourthParameter); is tolerated (well, maybe not the naming ...), but a space *without* the line-break between open-paren and firstParameter is forbidden. It remains that we got no consensus on the newline-comma pattern for classes; it mixes virtues and vices. Some maintainers will let you do that. Some won't. This reviewer has mixed feelings about it. > And since our coding conventions are that commas and semi- > colons have no space to the left, you can't insert a newline there either. > > Exception: complex #if, as in the declaration of qCompilerCpuFeatures in > qsimd_p.h and qsimd_x86_p.h: > > static const quint64 qCompilerCpuFeatures = 0 > #if defined __ARM_NEON__ > | CpuFeatureNEON > #endif > #if defined __ARM_FEATURE_CRC32 > | CpuFeatureCRC32 > #endif > #if defined __mips_dsp > | CpuFeatureDSP > #endif > #if defined __mips_dspr2 > | CpuFeatureDSPR2 > #endif > ; (The "no space allowed" point is just at the end, before the semicolon.) I see this as more an example of the one rule to rule them all: * When strictly following a rule makes your code look bad, feel free to break it https://wiki.qt.io/Qt_Coding_Style#General_exception It remains that this can apply equally justly to the newline-comma case (at least) when the last member of the class is subject to #if-ery, MyClass(type param) : MyBase(param), myMember(param) #if QT_CONFIG(myfeature) , myFeatureSpecificMember (param) #endif which, all things considered, is the case that I believe motivated the newline-comma pattern among various peers I've known who liked it. Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
