Re: [Development] the need to add a Task-Number in the release branch ...
On 13.11.13 13:38, "Oswald Buddenhagen" wrote: >moin, > >in >http://lists.qt-project.org/pipermail/development/2013-June/011610.html >thiago proposed that all changes pushed for release need to come with a >task-number footer. >the proposal met moderate approval. >little surprisingly, thiago seems to be the only person (i noticed) who >is actually enforcing this rule. and causing a lot of unnecessary churn, >imo. > >creating jira tasks just for the sake of being able to reference them in >the commit messages does not improve the quality of the git history. >the only purpose of the exercise is convincing the reviewers (and the >release team who stages the change, and possibly also yourself) that the >change actually does belong into the release branch. >as this pertains only to the review/integration process, i think it's >sufficient if all related activity is limited to the relevant tool: >gerrit. > >so my counter-proposal is this: >- you don't *need* to create a task just for the sake of it (of course > you should still do it if it really helps you). > as an alternative to actually creating and prioritizing a task, you > can do it as a thought exercise (and possibly mention your priority > estimate in the commit message). >- you need to convince the reviewer that the change is necessary to > start with. you do that in the commit message. > obviously, you should be doing that *anyway*, but maybe put a bit more > emphasis on it in release times. and keep it later on. ;) >- if the urgency of the change is not obvious to the reviewer, they'll > say that in a comment. > you may now need to amend the commit message (if some key information > is missing, e.g., that the change causes incompatibility). > other than that, the obvious recourse is doing the convincing in > followup comments. you may even write a comment pre-emptively. > >or to put is a bit concisely, the proposal is to simply pay attention to >the existing rules consistently instead of creating an entirely >unnecessary "paper trail". I agree with the proposal. But if there¹s no associated JIRA task, the commit message has to be clear and state why this change belongs into the release branch. Comments in gerrit are not good enough, as they are hard to trace. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging changes in release branch
Hi, You can check more detailed logs about the failed test cases Jani listed below from this change, contains all the "fail variations": https://codereview.qt-project.org/#change,70990 Br, Antti On 11/14/2013 08:36 AM, Heikkinen Jani wrote: > Hi! > Yes, as Lars said there is of course whole release team who is helping Antti > with this. At the moment biggest issue with this isn't staging itself but > failing test cases and there we need your help. Maintainer/Someone who really > understands needs to check those failing tests and either fix those or then > with good reason skip/mark those insignificant. We in the release team cannot > do that, we don't understand those tests well enough... > > These tests are blocked integration lately: > > tst_qgraphicsitem > tst_qqmlnotifier > tst_qgraphicsitem > tst_qvariant' > tst_qqmldebugjs > tst_languagechange > tst_qfiledialog > tst_qfiledialog2 > tst_qtreewidget > tst_qtreewidgetitemiterator > > br, > Jani > >> -Original Message- >> From: development-bounces+jani.heikkinen=digia@qt-project.org >> [mailto:development-bounces+jani.heikkinen=digia@qt-project.org] >> On Behalf Of Sean Harmer >> Sent: 13. marraskuuta 2013 21:47 >> To: development@qt-project.org >> Cc: Knoll Lars >> Subject: Re: [Development] Staging changes in release branch >> >> Hi Lars, >> >> On Wednesday 13 November 2013 19:33:59 Knoll Lars wrote: >>> On 13/11/13 18:49, "Sean Harmer" wrote: Hi, On Tuesday 12 November 2013 12:46:46 Heikkinen Jani wrote: > Hi all, > > We have agreed in release team that Antti Kokko (irc: ankokko) will > > monitor > > all approved changes in release branch and stage all clear ones (fixes > > for > > P1 & P0 issues) automatically. Unclear changes (p2 or lower + changes > without bug ID) will be handled case by case by change owner + release > > team > > (Antti will host discussion via email). > > For you who didn't know: Antti started 1.11.2013 in release team in > > Oulu. A > > lot of work and challenging tasks for him right from the start are the > > best > > way to learn. Whole release team will support Antti with all this! First of all thanks to Antti for taking this on. However, is it wise to have a single person be responsible for this? The issue is that we are still dealing with a CI system that see's issues with tests meaning that some changes take several attempts to get through the CI even if the change is good. Right now there are no changes either staged or integrating which is wasting the precious little time we have before the RC is tagged. I would therefore like to request that we have more than one person >> able to stage changes to help cover times when Antti is not available. >>> I believe we¹re already doing this. Antti helps to coordinate and stage >>> what he can. But other members of the release team and myself can (and >>> are) also staging during other hours for the stuff that¹s clear. >> OK great thanks. When you get a chance could you stage these please? >> >> https://codereview.qt-project.org/#change,70916 >> https://codereview.qt-project.org/#change,70848 >> >> These have both independently seen the same failure which we think is >> totally >> unrelated. >> >> Also: >> >> https://codereview.qt-project.org/#change,71036 >> https://codereview.qt-project.org/#change,71022 >> >> are both related and can go in together. >> >> The following were made by Marc following his analysis earlier today: >> >> https://codereview.qt-project.org/#change,71141 >> https://codereview.qt-project.org/#change,71142 >> https://codereview.qt-project.org/#change,71143 >> >> and can all go in together. >> >> Then for QtDeclarative: >> >> https://codereview.qt-project.org/#change,70917 >> >> should also hopefully pass all tests now and so could do with another spin >> please. >> >> Thanks, >> >> Sean >> -- >> Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK >> Klarälvdalens Datakonsult AB, a KDAB Group company >> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >> KDAB - Qt Experts - Platform-independent software solutions >> ___ >> 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging changes in release branch
Hi! Yes, as Lars said there is of course whole release team who is helping Antti with this. At the moment biggest issue with this isn't staging itself but failing test cases and there we need your help. Maintainer/Someone who really understands needs to check those failing tests and either fix those or then with good reason skip/mark those insignificant. We in the release team cannot do that, we don't understand those tests well enough... These tests are blocked integration lately: tst_qgraphicsitem tst_qqmlnotifier tst_qgraphicsitem tst_qvariant' tst_qqmldebugjs tst_languagechange tst_qfiledialog tst_qfiledialog2 tst_qtreewidget tst_qtreewidgetitemiterator br, Jani > -Original Message- > From: development-bounces+jani.heikkinen=digia@qt-project.org > [mailto:development-bounces+jani.heikkinen=digia@qt-project.org] > On Behalf Of Sean Harmer > Sent: 13. marraskuuta 2013 21:47 > To: development@qt-project.org > Cc: Knoll Lars > Subject: Re: [Development] Staging changes in release branch > > Hi Lars, > > On Wednesday 13 November 2013 19:33:59 Knoll Lars wrote: > > On 13/11/13 18:49, "Sean Harmer" wrote: > > >Hi, > > > > > >On Tuesday 12 November 2013 12:46:46 Heikkinen Jani wrote: > > >> Hi all, > > >> > > >> We have agreed in release team that Antti Kokko (irc: ankokko) will > > >> > > >>monitor > > >> > > >> all approved changes in release branch and stage all clear ones (fixes > > >> > > >>for > > >> > > >> P1 & P0 issues) automatically. Unclear changes (p2 or lower + changes > > >> without bug ID) will be handled case by case by change owner + release > > >> > > >>team > > >> > > >> (Antti will host discussion via email). > > >> > > >> For you who didn't know: Antti started 1.11.2013 in release team in > > >> > > >>Oulu. A > > >> > > >> lot of work and challenging tasks for him right from the start are the > > >> > > >>best > > >> > > >> way to learn. Whole release team will support Antti with all this! > > > > > >First of all thanks to Antti for taking this on. However, is it wise to > > >have a > > >single person be responsible for this? The issue is that we are still > > >dealing > > >with a CI system that see's issues with tests meaning that some changes > > >take > > >several attempts to get through the CI even if the change is good. > > > > > >Right now there are no changes either staged or integrating which is > > >wasting > > >the precious little time we have before the RC is tagged. > > > > > >I would therefore like to request that we have more than one person > able > > >to > > >stage changes to help cover times when Antti is not available. > > > > I believe we¹re already doing this. Antti helps to coordinate and stage > > what he can. But other members of the release team and myself can (and > > are) also staging during other hours for the stuff that¹s clear. > > OK great thanks. When you get a chance could you stage these please? > > https://codereview.qt-project.org/#change,70916 > https://codereview.qt-project.org/#change,70848 > > These have both independently seen the same failure which we think is > totally > unrelated. > > Also: > > https://codereview.qt-project.org/#change,71036 > https://codereview.qt-project.org/#change,71022 > > are both related and can go in together. > > The following were made by Marc following his analysis earlier today: > > https://codereview.qt-project.org/#change,71141 > https://codereview.qt-project.org/#change,71142 > https://codereview.qt-project.org/#change,71143 > > and can all go in together. > > Then for QtDeclarative: > > https://codereview.qt-project.org/#change,70917 > > should also hopefully pass all tests now and so could do with another spin > please. > > Thanks, > > Sean > -- > Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - Qt Experts - Platform-independent software solutions > ___ > 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] First Qt 5.2 RC1 snapshot available
no ios version installer T_T On Wed, Nov 13, 2013 at 9:08 PM, Heikkinen Jani wrote: > Hi all, > > There is now snapshot available: > http://download.qt-project.org/snapshots/qt/5.2/5.2.0-rc1/ > > > > Packages are now done from release branch and labeled as ‘rc1’. These are > first packages from release branch. Please test these and report your > findings immediately. As you should know we are planning to publish Qt 5.2 > RC1 next Tuesday 19th November 2013 so we need to fix all needed issues > during this week! > > > > No new Qt5 changes from release branch in these installers at this time, > just a merged content from stable. > > > > Qt5 changes after #134: > > > > * qtactiveqt > > > Doc: Updated url variable in qdocconf files. > > > > * qtandroidextras > > > Fix note about jni references in documentation. > > > Fix bug in code snippet. > > > Doc: Updated url variable in qdocconf files. > > > > * qtbase > > > Refactor QQnxWindow > > > Request the glyph at the right subpixel offset > > > Force FT font engine to load the right glyph metrics > > > Remove a boolean trap in QLayout::replaceWidget > > > QKeySequenceEdit: give nested line edit an objectName > > > QKeySequenceEdit: make setKeySequence a slot > > > Document the BC break of viewportSizeHint() in itemviews > > > Android native message dialog > > > Avoid signed integer overflow by making an addition a subtraction > > > QTimeZone - Fix Windows Transitions > > > QTimeZone - Fix Mac Transistions > > > Move QTreeView::accessibleTree2Index to the private class > > > QHeaderView - remove confusing bool > > > QSslConfiguration: rename [get]session() to [get]sessionTicket() > > > iOS: Send expose event when a window changes the geometry. > > > Remove disused version of QPlatformMessageDialogHelper::clicked signal > > > Fix QFileDialog::getSaveFilename() with a given default name > > > Doc: Move threading overviews from qtbase.git to qtdoc.git > > > Doc: Added some Qt Quick examples to manifest-meta.qdocconf > > > Prevent clang from warning about unused variables > > > QVariant: Convert automatically from enum types to integral types. > > > Fix QVariant::canConvert with longlong > > > Revert "Fix setVisible() of QWidget has no effect in QTreeWidgetItem" > > > NSUrlConnection backend for QNetworkAccessManager > > > Prevent a crash in QLayout::replaceWidget > > > Cocoa File Dialog: Remove sandbox-ufriendly file system watcher > > > Fix potential BC break in QColorDialog. > > > Fix potential BC break in QTabBar. > > > iOS: Cancel any active touches when destroying a QIOSWindow > > > iOS: Detect/handle cancellation of subset of touch points > > > iOS: Rename QIOSWindows backing view from EAGLView to QUIView > > > iOS: Rename m_requestedGeometry to m_normalGeometry > > > Cocoa: fix a crash in QCocoaFileDialogHelper > > > qfeatures.txt: add section about XML schema > > > Dialogs: provide the StandardButton->ButtonRole mapping in QPA > > > Android: Allow modules to specify permissions/features > > > add/remove window only when the window is shown/hidden > > > Windows: Do not set transient parent on popups. > > > Add a warning message when a WM_DESTROY not triggered by Qt is received. > > > Revert "Add tracing to logging framework" > > > qdoc: Dont include internal QML types > > > qdoc: Fix output file name generation for examples > > > QNX: Fixed "normalPosition" of touch events > > > Add missing Q_INIT_RESOURCE > > > Android: allow installing apps to SD card by default > > > tst_QFlags: make constExpr() check compile on clang trunk > > > QUrlTwoFlag: add two missing constexpr > > > Q(UrlTwo)Flags: avoid undefined behavior > > > iOS: set active window upon calls to requestActiveWindow > > > Doc: Fix cross-module links > > > EglFS: make sure resize events are delivered > > > Android: Fix registerClipboardManager semaphore initialization > > > Android: Catch any startActivity exceptions > > > QMetaType: Fix conversion between module types. > > > Android: Fix menu on API-11+ > > > iOS: Remove unused QIOSWindow methods for getting effective width/height > > > Clarify Q_INIT_RESOURCE in relation to namespaces > > > Dont hardcode devicePixelRatio to 1. > > > Doc: update Qt Creator external pages > > > Revert "Use Qts own glyph cache with the freetype engine." > > > Android: prevent main activity to be recreated. > > > Doc: Updated url variable in qdocconf files. > > > Add note about fullscreen on Android to changes-5.2.0 > > > Make OpenGL texture glyph cache use the right freetype glyphs > > > QGlobal: static_assert that sizeof(int) == 4 and UCHAR_MAX == 255 > > > Force length fo licensee literals to be computed at runtime > > > Doc: Add a little more information about current dirs > > > Remove two unused functions from QAccessibleTabBar > > > QIntegerForSize: add test > > > Disable threaded rendering for Intel HD 3000 cards. > > > Revert "Ensure CSS rules are inherited from the parent tags" > > > Add missing \since 5.1 for QVector::takeFirst() and ::takeLast() > > >
[Development] Audio playback depends on... Qt5Widgets.dll?
Hello, I just found out that my Qt Quick 2 application can't use the Audio element unless I deploy Qt5Widgets.dll along with it. Otherwise, I get this at runtime: defaultServiceProvider::requestService(): no service found for - "org.qt-project.qt.mediaplayer" I then wrote a console application that does nothing except play a .wav file through QMediaPlayer. Same result -- the sound plays if Qt5Widgets.dll is present, but "no service found" otherwise. Is this expected? I understand the dependency on the Qt GUI module -- QMediaPlayer handles videos -- but what's required from the Qt Widgets module for multimedia playback? More importantly, is it possible to remove this dependency? Regards, Sze-Howe (Tested on Qt 5.1.1 and Qt 5.2.0 Beta, Windows 8.1 x64, MSVC 2012 OpenGL) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats
On Nov 8, 2013, at 9:53 AM, Knoll Lars wrote: > +1 to moving the plugins to qtimageformats. That¹s what we have the module > for. > > And I don¹t think moving ICNS is an issue neither, as long as we have a > configure test in qtimageformats to detect whether we can compile the > plugin. > > Cheers, > Lars I've begun the process of moving the JPEG 2000 handler to QtImageFormats. https://codereview.qt-project.org/#change,71245 https://codereview.qt-project.org/#change,71246 I did the minimum necessary to get the JP2 plugin fitting with the layout of the existing repository - filenames, class names, fixed code style (indentation, d-pointer) and spelling errors in comments enough to quiet sanity bot, but other than that no significant changes were made. Amazingly, the ancient JasPer still builds on modern OS X 10.9. I used version 1.701.0 in my testing as a comment in the Qt Solutions documentation indicated that the latest 1.900.1 does not work. Build and install JasPer (default install prefix is /usr/local): ./configure --enable-shared make sudo make install Build and test QtImageFormats: qmake -r make cd tests/ make check The JP2 plugin should be built and should work; I turned the example from the Qt Solutions versions into an autotest. The plugin code looks very messy and the testing is obviously minimal, but any cleanup and possible replacement of JasPer with OpenJPEG as previously discussed, can be done in a followup commit if someone's up to the task. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
On Sat, Nov 9, 2013 at 12:50 PM, Olivier Goffart wrote: > Allow me to disagree :-) > How usefull are 1-4 without 99? What exactly can you do with that > information. I think that in the meantime this has been well reasoned by Kai-Uwe and John: It could be a sane starting point and be needed API for later steps -also from your suggested list-, anyways. Also, I was indeed just thinking about color correcting opaque images and colors. Less about blending, anti-aliasing or gradients. But let's combine our fields, then. > 1) QImage[Reader] converts automatically to linear color space, so that all > QImage's are in the linear color space A few cents regarding ICC profile usage: How would we do the linearization; by using the image profile to transform the image data (what about alpha channel)? And with which output profile (i.e. to which color space)? Note that there really is no meaningful "RGB" without Profile/Colorspace, unless we define a linear qtRgb space for that and ship a profile for that with Qt. I believe that Lab would actually be the right intermediate space for what you suggest. It is afaik really linear to our eyes, can contain all RGB/CMYK gamuts, and is in the first place a natural intermediate format when transforming from one device space to the other (e.g. from digital camera A to computer screen B). It would therefore make late and early color binding (Kai-Uwe's mail) workflows co-exist peacefully. We would have to consider white point handling, but that's a minor detail. However, all our RGB-based algorithms would have to be re-implemented in Lab, of course minimum 16 bits per channel, which basically already kills my suggetion :p > 2) A conversion to the screen's colorspace is done "at the end" (by the > platform plugin? by the compositor?) Definitely a workflow which app developers will want. Especially when using QtWebkit, since now most web browsers can do that. But good question... by whom, on which platform. That's what made push my mile stone to 99. Good discussion, let's keep the ball rolling! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging changes in release branch
Hi Lars, On Wednesday 13 November 2013 19:33:59 Knoll Lars wrote: > On 13/11/13 18:49, "Sean Harmer" wrote: > >Hi, > > > >On Tuesday 12 November 2013 12:46:46 Heikkinen Jani wrote: > >> Hi all, > >> > >> We have agreed in release team that Antti Kokko (irc: ankokko) will > >> > >>monitor > >> > >> all approved changes in release branch and stage all clear ones (fixes > >> > >>for > >> > >> P1 & P0 issues) automatically. Unclear changes (p2 or lower + changes > >> without bug ID) will be handled case by case by change owner + release > >> > >>team > >> > >> (Antti will host discussion via email). > >> > >> For you who didn't know: Antti started 1.11.2013 in release team in > >> > >>Oulu. A > >> > >> lot of work and challenging tasks for him right from the start are the > >> > >>best > >> > >> way to learn. Whole release team will support Antti with all this! > > > >First of all thanks to Antti for taking this on. However, is it wise to > >have a > >single person be responsible for this? The issue is that we are still > >dealing > >with a CI system that see's issues with tests meaning that some changes > >take > >several attempts to get through the CI even if the change is good. > > > >Right now there are no changes either staged or integrating which is > >wasting > >the precious little time we have before the RC is tagged. > > > >I would therefore like to request that we have more than one person able > >to > >stage changes to help cover times when Antti is not available. > > I believe we¹re already doing this. Antti helps to coordinate and stage > what he can. But other members of the release team and myself can (and > are) also staging during other hours for the stuff that¹s clear. OK great thanks. When you get a chance could you stage these please? https://codereview.qt-project.org/#change,70916 https://codereview.qt-project.org/#change,70848 These have both independently seen the same failure which we think is totally unrelated. Also: https://codereview.qt-project.org/#change,71036 https://codereview.qt-project.org/#change,71022 are both related and can go in together. The following were made by Marc following his analysis earlier today: https://codereview.qt-project.org/#change,71141 https://codereview.qt-project.org/#change,71142 https://codereview.qt-project.org/#change,71143 and can all go in together. Then for QtDeclarative: https://codereview.qt-project.org/#change,70917 should also hopefully pass all tests now and so could do with another spin please. Thanks, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging changes in release branch
On 13/11/13 18:49, "Sean Harmer" wrote: >Hi, > >On Tuesday 12 November 2013 12:46:46 Heikkinen Jani wrote: >> Hi all, >> >> We have agreed in release team that Antti Kokko (irc: ankokko) will >>monitor >> all approved changes in release branch and stage all clear ones (fixes >>for >> P1 & P0 issues) automatically. Unclear changes (p2 or lower + changes >> without bug ID) will be handled case by case by change owner + release >>team >> (Antti will host discussion via email). >> >> For you who didn't know: Antti started 1.11.2013 in release team in >>Oulu. A >> lot of work and challenging tasks for him right from the start are the >>best >> way to learn. Whole release team will support Antti with all this! > >First of all thanks to Antti for taking this on. However, is it wise to >have a >single person be responsible for this? The issue is that we are still >dealing >with a CI system that see's issues with tests meaning that some changes >take >several attempts to get through the CI even if the change is good. > >Right now there are no changes either staged or integrating which is >wasting >the precious little time we have before the RC is tagged. > >I would therefore like to request that we have more than one person able >to >stage changes to help cover times when Antti is not available. I believe we¹re already doing this. Antti helps to coordinate and stage what he can. But other members of the release team and myself can (and are) also staging during other hours for the stuff that¹s clear. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Maintainership of QtNetwork
I would often have discussions with Peter and Rich over IRC about complex QtNetwork issues and I am confident in their ability to work together on this. If for organisational reasons it is preferred to have single maintainers, I'd suggest Rich for the socket/SSL/security parts and Peter for QNetworkAccessManager with one of them as the overall module maintainer. (in the same way that the gui module was subdivided between several maintainers) On 5 November 2013 20:58, André Pönitz < andre.poen...@mathematik.tu-chemnitz.de> wrote: > On Mon, Nov 04, 2013 at 08:49:45PM -0800, Alan Alpert wrote: > > >> > As some of you may know, Shane has a new job and therefore has a lot > > >> > less time to spend on QtNetwork. He, Peter and I have discussed how > > >> > we should maintain the module in the future. What we're proposing is > > >> > that Peter and I take over as joint maintainers since neither of us > > >> > has the time to keep on top of things alone. Anyone looking to help > > >> > out in this area should feel free to drop us a mail. > > >> > > >> This isn't a veto or anything, but having two 'equal' maintainers for > > >> the same area sounds odd to me. I mean, it's perfectly fine that you > > >> split up the workload, but the point of having a nominal maintainer is > > >> to have _one_ person to go to, and _one_ person who can decide if > > >> there's need ... It doesn't mean that the maintainer can't delegate > > >> his work though, up to the point that whomever he trusts can act as a > > >> de-facto decision maker, too. > > > > > > Well, I am pretty much in the other camp. I see no problem here, > > > neither of the setup in general (better bus factor, less chance of > > > overload, something that rather should be encouraged...) nor with Rich > > > and Peter in particular. > > > > You're missing the point of having a hierarchy, deliberately assign clear > > bottlenecks for responsibility (and they shouldn't be used that often). > > You are focusing on a secondary aspect while masking out the primary issue. > > The goal of the project is to create a usable product. > > Having a hierarchy might or might not be beneficial in achieving that goal. > So far the assumption was that having it bears quite some value, as it > helps to establish and to keep order. However, the hierarchy is not the > primary goal. > > If two people, both with quite impressive track records in the project, ask > to share the responsibilities of one position, the question is not whether > it fits into the hierarchy, but whether it is beneficial for the project. > > Answering that question might involve considerations of practicability, and > more, but theoretical considerations about the primacy of artifically > introduced bottlenecks are unlikely to help. > > Andre' > > > PS: > > > Back from the general to the specific, I'm definitely happy with > > Richard and Peter stepping up if Shane no longer has time. It's better > > to have too many good maintainers for a module than too few. > > > > Since I think it'll be a long time until we hit a situation where the > > designated tie breaker rule will be needed, I'd suggest we vote them > > both in first and then tackle the general question of "shared > > maintainerships" separately. > > I even agree. > ___ > 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] the need to add a Task-Number in the release branch ...
On Wed, Nov 13, 2013 at 4:38 AM, Oswald Buddenhagen wrote: > moin, > > in > http://lists.qt-project.org/pipermail/development/2013-June/011610.html > thiago proposed that all changes pushed for release need to come with a > task-number footer. > the proposal met moderate approval. > little surprisingly, thiago seems to be the only person (i noticed) who > is actually enforcing this rule. and causing a lot of unnecessary churn, > imo. > > creating jira tasks just for the sake of being able to reference them in > the commit messages does not improve the quality of the git history. > the only purpose of the exercise is convincing the reviewers (and the > release team who stages the change, and possibly also yourself) that the > change actually does belong into the release branch. > as this pertains only to the review/integration process, i think it's > sufficient if all related activity is limited to the relevant tool: > gerrit. > > so my counter-proposal is this: > - you don't *need* to create a task just for the sake of it (of course > you should still do it if it really helps you). > as an alternative to actually creating and prioritizing a task, you > can do it as a thought exercise (and possibly mention your priority > estimate in the commit message). > - you need to convince the reviewer that the change is necessary to > start with. you do that in the commit message. > obviously, you should be doing that *anyway*, but maybe put a bit more > emphasis on it in release times. and keep it later on. ;) > - if the urgency of the change is not obvious to the reviewer, they'll > say that in a comment. > you may now need to amend the commit message (if some key information > is missing, e.g., that the change causes incompatibility). > other than that, the obvious recourse is doing the convincing in > followup comments. you may even write a comment pre-emptively. > > or to put is a bit concisely, the proposal is to simply pay attention to > the existing rules consistently instead of creating an entirely > unnecessary "paper trail". The "paper trail" is necessary for history and for communicating with others and what I'm seeing here is that you want to be able to have it entirely in gerrit (you haven't asked for any relevant "content" to be dropped, just moved to review comments). Gerrit is the wrong tool for that, review comments are not easily searchable. Even git is not always that great, especially since we tell people that JIRA is where we track issues and so that's the first place people will look. I'm fine with the enhanced scrutiny on release branch when theoretically *all* commits should have a JIRA task associated (even though everyone agrees that it's not worth bothering with that for most work). My only problem is that resubmitting the patches can be a problem (needs to be at a workstation set up for development, then needs to be re-approved). I'd recommend (and have kind of been doing) that it's okay to just add the JIRA task number as a comment on gerrit. Then you don't get the automatic JIRA source integration, but it's easy enough to put in a comment with the link to the codereview change (mitigating the 'searchable' problem) or filling out the changes field yourself (ah, that takes me back ;) ). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging changes in release branch
Hi, On Tuesday 12 November 2013 12:46:46 Heikkinen Jani wrote: > Hi all, > > We have agreed in release team that Antti Kokko (irc: ankokko) will monitor > all approved changes in release branch and stage all clear ones (fixes for > P1 & P0 issues) automatically. Unclear changes (p2 or lower + changes > without bug ID) will be handled case by case by change owner + release team > (Antti will host discussion via email). > > For you who didn't know: Antti started 1.11.2013 in release team in Oulu. A > lot of work and challenging tasks for him right from the start are the best > way to learn. Whole release team will support Antti with all this! First of all thanks to Antti for taking this on. However, is it wise to have a single person be responsible for this? The issue is that we are still dealing with a CI system that see's issues with tests meaning that some changes take several attempts to get through the CI even if the change is good. Right now there are no changes either staged or integrating which is wasting the precious little time we have before the RC is tagged. I would therefore like to request that we have more than one person able to stage changes to help cover times when Antti is not available. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] DirectDraw Surface
Thanks for quick reply! I think, you can represent cubemap as an array with 6 images (right now, i generate one big texture that includes all 6 images, but i can separate them) and use QImageReader to read that array. Not sure if this works for texture arrays, i didn't explore that part of the format. Иван Комиссаров 13 нояб. 2013 г., в 20:54, Sean Harmer написал(а): > Hi, > > On Wednesday 13 November 2013 20:36:06 Иван Комиссаров wrote: >> Hello, i've uploaded initial version of my DirectDraw Surface image handler >> https://codereview.qt-project.org/#change,71216 > > Very interesting! Adding support for DDS files is something I'm looking to do > for Qt 5.3 to improve the OpenGL texture support. The nice thing is that this > format includes support for mipmap chains, cubemap faces and texture arrays. > Of course QImage doesn't support any of these things. So with this in mind, > would it make sense to refactor the DDS loading part into a library that can > be used by the image handler here and some future QOpenGLTextureData class > which can be used to manipulate all of the images supported by DDS and KTX > files http://www.khronos.org/opengles/sdk/tools/KTX/ > >> Are there anyone who is familiar with this format who can do a review? > > I'm not intimately familiar with the internal workings but I can certainly > take a look when things calm down a little. > > Thanks for the contribution. > > Sean > -- > Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - Qt Experts - Platform-independent software solutions > ___ > 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] DirectDraw Surface
Hi, On Wednesday 13 November 2013 20:36:06 Иван Комиссаров wrote: > Hello, i've uploaded initial version of my DirectDraw Surface image handler > https://codereview.qt-project.org/#change,71216 Very interesting! Adding support for DDS files is something I'm looking to do for Qt 5.3 to improve the OpenGL texture support. The nice thing is that this format includes support for mipmap chains, cubemap faces and texture arrays. Of course QImage doesn't support any of these things. So with this in mind, would it make sense to refactor the DDS loading part into a library that can be used by the image handler here and some future QOpenGLTextureData class which can be used to manipulate all of the images supported by DDS and KTX files http://www.khronos.org/opengles/sdk/tools/KTX/ > Are there anyone who is familiar with this format who can do a review? I'm not intimately familiar with the internal workings but I can certainly take a look when things calm down a little. Thanks for the contribution. Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] DirectDraw Surface
Hello, i've uploaded initial version of my DirectDraw Surface image handler https://codereview.qt-project.org/#change,71216 Are there anyone who is familiar with this format who can do a review? Иван Комиссаров ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
Am 10.11.2013 11:05, schrieb John Layt: > On 9 November 2013 12:50, Olivier Goffart wrote: >> On Saturday 09 November 2013 03:02:18 Alessandro Portale wrote: >>> I like the idea of re-starting small, and quite a bit of what was done >>> in Nokia times can certainly be re-used. >>> What if Qt started by simply *enabling* color management. I.e. giving >>> access to the information that an application needs to perform color >>> management tasks itself. In a much later iteration Qt could perhaps >>> perform color management operations. Qt should IMHO avoid automatic >>> color management under the hood, especially without providing API to >>> control it. >>> >>> Milestones could be: >>> 1) QImage[Reader] gives access to image color profile. Either whole >>> profile or just an identifier in case of standard spaces such as sRgb. >>> 2) QScreen gives access to the current display color profile for that >>> specific screen. >>> 3) There are notifications (signals?) when the a window changes to >>> another screen, or when a screen profile is changed in the system. >>> 4) Same as "2" but for installed Printers on the system. >>> ... >>> 99) QColorEngine can do color conversions using an input profile, a >>> source Image an output profile plus different parameters. >>> >>> Ideas? Kai-Uwe, what color management feature (or enabler) are you >>> missing most in Qt? >> Allow me to disagree :-) >> How usefull are 1-4 without 99? What exactly can you do with that >> information. > Well, I'm no expert at the graphics side of things, but I think before > you can start applying a color profile you need to know what color > profile to apply :-) If we at least expose that config for apps to > use then they only need to apply the transforms themselves, rather > than also having to abstract the system config. Then afterwards we > can start using the config ourselves in our own code. OTOH we don't > want to ship api that we may have to change later when we start using > it ourselves in anger. > > I think step 1 is very definitely a cross-platform api to access the > host system config and profiles, regardless of whether we make it > public or not. That's easy enough for Windows and Mac where each has > a single color management framework built-in, but on Linux we still > have two competing systems (perhaps Kai-Uwe can update us on that > situation, is there a single combined config yet?). Most applications use for Xorg the ICC Profile in X spec [1]. The spec is served by Oyranos CMS as well as the colord CMS and others. > Now, to really expose my lack of knowledge, AFAIK Mac especially and > Windows graphics contexts can apply the required transforms themselves > internally, so wherever we use the native context it's surely just a > case of configuring them to do the work for us? It's really only on > Linux or XP that we would have to have code for doing the transforms > ourselves using LCMS? But like I said, I know nothing of our graphics > internals :-) Lcms is for realtime conversions too slow. OpenGL provides in some profiles a 3D texture lookup on the GPU, which is fast. kind regards Kai-Uwe Behrmann [1] http://www.openicc.info/index.php?title=ICC_Profiles_in_X_Specification_0.4 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] First Qt 5.2 RC1 snapshot available
Hi all, There is now snapshot available: http://download.qt-project.org/snapshots/qt/5.2/5.2.0-rc1/ Packages are now done from release branch and labeled as 'rc1'. These are first packages from release branch. Please test these and report your findings immediately. As you should know we are planning to publish Qt 5.2 RC1 next Tuesday 19th November 2013 so we need to fix all needed issues during this week! No new Qt5 changes from release branch in these installers at this time, just a merged content from stable. Qt5 changes after #134: * qtactiveqt > Doc: Updated url variable in qdocconf files. * qtandroidextras > Fix note about jni references in documentation. > Fix bug in code snippet. > Doc: Updated url variable in qdocconf files. * qtbase > Refactor QQnxWindow > Request the glyph at the right subpixel offset > Force FT font engine to load the right glyph metrics > Remove a boolean trap in QLayout::replaceWidget > QKeySequenceEdit: give nested line edit an objectName > QKeySequenceEdit: make setKeySequence a slot > Document the BC break of viewportSizeHint() in itemviews > Android native message dialog > Avoid signed integer overflow by making an addition a subtraction > QTimeZone - Fix Windows Transitions > QTimeZone - Fix Mac Transistions > Move QTreeView::accessibleTree2Index to the private class > QHeaderView - remove confusing bool > QSslConfiguration: rename [get]session() to [get]sessionTicket() > iOS: Send expose event when a window changes the geometry. > Remove disused version of QPlatformMessageDialogHelper::clicked signal > Fix QFileDialog::getSaveFilename() with a given default name > Doc: Move threading overviews from qtbase.git to qtdoc.git > Doc: Added some Qt Quick examples to manifest-meta.qdocconf > Prevent clang from warning about unused variables > QVariant: Convert automatically from enum types to integral types. > Fix QVariant::canConvert with longlong > Revert "Fix setVisible() of QWidget has no effect in QTreeWidgetItem" > NSUrlConnection backend for QNetworkAccessManager > Prevent a crash in QLayout::replaceWidget > Cocoa File Dialog: Remove sandbox-ufriendly file system watcher > Fix potential BC break in QColorDialog. > Fix potential BC break in QTabBar. > iOS: Cancel any active touches when destroying a QIOSWindow > iOS: Detect/handle cancellation of subset of touch points > iOS: Rename QIOSWindows backing view from EAGLView to QUIView > iOS: Rename m_requestedGeometry to m_normalGeometry > Cocoa: fix a crash in QCocoaFileDialogHelper > qfeatures.txt: add section about XML schema > Dialogs: provide the StandardButton->ButtonRole mapping in QPA > Android: Allow modules to specify permissions/features > add/remove window only when the window is shown/hidden > Windows: Do not set transient parent on popups. > Add a warning message when a WM_DESTROY not triggered by Qt is received. > Revert "Add tracing to logging framework" > qdoc: Dont include internal QML types > qdoc: Fix output file name generation for examples > QNX: Fixed "normalPosition" of touch events > Add missing Q_INIT_RESOURCE > Android: allow installing apps to SD card by default > tst_QFlags: make constExpr() check compile on clang trunk > QUrlTwoFlag: add two missing constexpr > Q(UrlTwo)Flags: avoid undefined behavior > iOS: set active window upon calls to requestActiveWindow > Doc: Fix cross-module links > EglFS: make sure resize events are delivered > Android: Fix registerClipboardManager semaphore initialization > Android: Catch any startActivity exceptions > QMetaType: Fix conversion between module types. > Android: Fix menu on API-11+ > iOS: Remove unused QIOSWindow methods for getting effective width/height > Clarify Q_INIT_RESOURCE in relation to namespaces > Dont hardcode devicePixelRatio to 1. > Doc: update Qt Creator external pages > Revert "Use Qts own glyph cache with the freetype engine." > Android: prevent main activity to be recreated. > Doc: Updated url variable in qdocconf files. > Add note about fullscreen on Android to changes-5.2.0 > Make OpenGL texture glyph cache use the right freetype glyphs > QGlobal: static_assert that sizeof(int) == 4 and UCHAR_MAX == 255 > Force length fo licensee literals to be computed at runtime > Doc: Add a little more information about current dirs > Remove two unused functions from QAccessibleTabBar > QIntegerForSize: add test > Disable threaded rendering for Intel HD 3000 cards. > Revert "Ensure CSS rules are inherited from the parent tags" > Add missing \since 5.1 for QVector::takeFirst() and ::takeLast() > QStandardPaths: add GenericConfigLocation > tst_qurl: add test for matches() with empty vs null case > Add better version checks for accessibility > Support native event filters for screen events > Declare Cocoa conversion funcs in objc-mode only. > Cocoa (OpenGL): If no view is attached, makeCurrent() should return false > Cocoa: Dont hide views when reparenting > Improve documentation of QImageIOPlugin > Fix placeholder text in QTextBrowser > T
[Development] the need to add a Task-Number in the release branch ...
moin, in http://lists.qt-project.org/pipermail/development/2013-June/011610.html thiago proposed that all changes pushed for release need to come with a task-number footer. the proposal met moderate approval. little surprisingly, thiago seems to be the only person (i noticed) who is actually enforcing this rule. and causing a lot of unnecessary churn, imo. creating jira tasks just for the sake of being able to reference them in the commit messages does not improve the quality of the git history. the only purpose of the exercise is convincing the reviewers (and the release team who stages the change, and possibly also yourself) that the change actually does belong into the release branch. as this pertains only to the review/integration process, i think it's sufficient if all related activity is limited to the relevant tool: gerrit. so my counter-proposal is this: - you don't *need* to create a task just for the sake of it (of course you should still do it if it really helps you). as an alternative to actually creating and prioritizing a task, you can do it as a thought exercise (and possibly mention your priority estimate in the commit message). - you need to convince the reviewer that the change is necessary to start with. you do that in the commit message. obviously, you should be doing that *anyway*, but maybe put a bit more emphasis on it in release times. and keep it later on. ;) - if the urgency of the change is not obvious to the reviewer, they'll say that in a comment. you may now need to amend the commit message (if some key information is missing, e.g., that the change causes incompatibility). other than that, the obvious recourse is doing the convincing in followup comments. you may even write a comment pre-emptively. or to put is a bit concisely, the proposal is to simply pay attention to the existing rules consistently instead of creating an entirely unnecessary "paper trail". ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Reviewing new classes (was: Re: Qt 5.2 header diff)
On Friday, November 08, 2013 13:59:00 Heikkinen Jani wrote: > Hi all, > > What is the situation with reviews & especially potential fixes? Is all > needed now done and so on can we start merge on Monday morning? Maybe I missed the mail, but there was no explict round of review of new classes. I've reviewed the new classes (at least those that come with new files[1]) in QtCore, QtGui, and QtWidgets. core: https://codereview.qt-project.org/71116 https://codereview.qt-project.org/71117 https://codereview.qt-project.org/71118 https://codereview.qt-project.org/71119 https://codereview.qt-project.org/71120 https://codereview.qt-project.org/71129 https://codereview.qt-project.org/71131 https://codereview.qt-project.org/71132 https://codereview.qt-project.org/71133 https://codereview.qt-project.org/71134 gui: https://codereview.qt-project.org/71141 https://codereview.qt-project.org/71142 https://codereview.qt-project.org/71143 When adding new value classes, please check that they a) are marked Q_DECLARE_SHARED if they are Q_MOVABLE_TYPE and copyable, even if they are not implictly shared. The macro should be renamed to Q_DECLARE_VALUE_CLASS at some point :) b) (necessary for (a)) have an inline member-swap function c) have an inline move assignment operator d) if they use a naked pointer as d-pointer, have an inline move constructor When adding any class, please check that ctors are marked either as explicit or /*implicit*/. Thanks, Marc [1] I used this command to find them: git log --diff-filter=A --stat v5.1.1..gerrit/release -- src | grep src | \ grep \\.h | grep -v _p\\.h | cut -d\ -f2 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
