Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available
On domingo, 24 de fevereiro de 2013 06.43.24, Turunen Tuukka wrote: Getting back to the topic of these releases - what is our decision? Shall we do the RC2 as proposed, but with shmget fix in 4.7.6, and later go to release unless problems are found? This would mean we accept that there is not perfect history available and that we trust the way changes were cherry-picked to 4.6.4 and 4.7.5. Or shall we leave the history as it is and not release these? I think that the contents that you were proposing to release are *probably* fine, provided that we add the shmget fix. However, I can't be sure because the diff between the two branches is unreviewable, since every header is modified. Someone needs to produce a clean diff we can review and post to the list. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Compiling with GCC 4.8
On sábado, 23 de fevereiro de 2013 23.19.33, David Narvaez wrote: On Sat, Feb 23, 2013 at 12:29 PM, Thiago Macieira thiago.macie...@intel.com wrote: I haven't seen any patches fixing warnings or compilation errors come in for 4.8. Usually, there are a few warnings that need fixing but until my -Werror patches land, those are not stoppers. Usually, there are no compilation errors. No one has reported anything. Well, I think I got scared with the amount of errors I got from my first try but apparently it is all solved with a rather simple patch I have put on codereview. I added you as a reviewer, if anybody else is interested just let me know. Thanks, I approved it. The change makes sense. I've just tried GCC 4.8 (SVN 196167) compiled locally and it produced a good number of warnings like: qdbusargument.cpp:1138:30: error: ‘d’ may be used uninitialized in this function [-Werror=maybe-uninitialized] It looks like it inlined the operator(int) call and realised that there's a codepath where the variable isn't initialised. But unfortunately, it crashed: io/qsettings.cpp:466:9: internal compiler error: Segmentation fault QString QSettingsPrivate::variantToString(const QVariant v) ^ 0x5a140c crash_signal ../../gcc/toplev.c:334 [...] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Setting the priority of bug reports created the Qt Support team
Before the transition to Qt being developed in the open via open governance, the Qt Support team back in Trolltech and later Nokia, would prioritize the bugs that were created, or at least handled, by them. Typically these would be bugs that were brought to our attention by commercial customers using Qt. As we know the bug fairly well at this point, and have an understanding of the impact it has on applications, then we were in a position to set a reasonable priority setting. Since the move to develop in the open via open governance, this has not been kept up, as it was back then not desired that the Qt Support team would continue this practice. What I would like to suggest that we do now is bring back this practice, so that the Qt Support team will set a priority on the bugs that it creates or handles, so that it makes things easier for the maintainers to actually see what issues are potentially a higher priority than the others. And in the case of the high priority issues, it will draw attention to them faster rather than them being picked up later on in the process. I have also discussed this with the developers inside Digia, and they see a need for getting help when triaging the bugs, so having the Qt Support team set a priority here would at least go some way to helping with that. Of course any priority set by the Qt Support team is intended to be a guideline, the maintainer would still be at liberty to change it if they disagree. Is there any comments, thoughts or concerns about this proposal? If I don't hear any objections, then we will move ahead with this starting within the next week. I know that there are still side discussions related to this, but there were no objections to the support team in Digia at least prioritizing the issues they create so we will start doing this as of today. Regards, Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
