Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Jedrzej Nowacki]

On Friday, June 28, 2019 11:32:43 AM CEST Cristian Adam wrote:
> Hi,
> 
> Some of you might have been familiar with white papers such as Qt QML v
> HTML5 – a practical
> comparison %20QT4/WHITEPAPER_HTML5vQML.pdf>.
 
> Qt Creator already ships with QML support, why not transform the HTML
> offline documentation into QML?
 Does it have to be HTML5/CSS?
> 
> Having the documentation as QML will have no additional constrains for Qt
> Creator. No 76MiB Qt5WebEngineCore.dll file, no memory increase, no startup
> penalty.
 
> QML is supported on all platforms, right? Builds with MinGW on Windows, and
> so on.
 
> Cheers,
> Cristian.

10 points for thinking out of the box :-) 

It would solve a lot of problems like; scaling, integration, fonts, _embedding 
qml snippets_, binary size... It would leave us with security issues, we could 
restrict the content somehow (documentation viewer would need to be 
sandboxed). As I like the idea, some prototyping is needed :-)

Cheers,
  Jędrek


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

Re: [Development] New repository request (qtplatformdefinitions)

[Jedrzej Nowacki]

On Tuesday, June 25, 2019 12:23:55 PM CEST Tor Arne Vestbø wrote:
> The name qtplatformdefinitions will likely quickly be wrong once something
> else needs to be dumped in there. How about just qtinfra?
 
> Tor Arne 
> 

I'm not really asking for "catch all" repository. I do not know why anything 
else that I mentioned in the bug tracker would be needed to be dumped there. I 
just need a repository with no dependencies following qt branching model to 
store build instructions, specifying CI tested platforms and probably storing 
some provisioning scripts. All CI related. It can be named qtinfra, 
qtinfrastructure, qtci, qtplatformdefinitions or even qtfoobar I will accept 
anything without a fight :-)

Jędrek


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

[Development] New repository request (qtplatformdefinitions)

[Jedrzej Nowacki]

As in: https://bugreports.qt.io/browse/QTQAINFRA-3068

We need a repository for infrastructure, so we do not need to abuse qt5 
repository anymore.

Cheers,
  Jędrek


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

Re: [Development] Proposing CMake as build tool for Qt 6

[Jedrzej Nowacki]

On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:
> On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:
> > You can download a CMake static binary (https://cmake.org/download/) that
> 
> (...)
> 
> I would prefer that our requirements be present in Linux distributions we
> declare are supported build environments. If nothing else, our CI will
> benefit from this.

Let's not pull CI into it. It already covers installation of the cmake in 
order to test wip/cmake branch (https://code.qt.io/cgit/qt/qt5.git/tree/coin/
provisioning/common/linux/cmake_linux.sh?h=wip/cmake)

Cheers,
  Jędrek


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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Jedrzej Nowacki]

On Saturday, June 1, 2019 5:36:35 AM CEST Thiago Macieira wrote:
> On Friday, 31 May 2019 10:13:52 PDT Thiago Macieira wrote:
> > rcc should be un-bootstrapped. The only use inside QtCore is for the MIME
> > type database. We don't need a resource, though it compresses really well
> > (roughly 10:1 with zstd). I'd simply make that a read-only sharable
> > variable, which we can easily create with a C++11 raw string.
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/263548
> 
> Unfortunately, MSVC doesn't want to cooperate:
> 
> .\qmimeprovider_database.cpp(1270): fatal error C1091: compiler limit:
> string exceeds 65535 bytes in length
> 

moc had similar problem, it was solved by generating something like that:

struct {
  char[65535] 
  char[65535]
  
}

instead of a string.

Cheers,
  Jędrek



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

Re: [Development] QVariant container API

[Jedrzej Nowacki]

On Monday, April 1, 2019 11:09:27 AM CEST Vasily Pupkin wrote:
> Hi.
> 
> I would like to submit a patch. Since it is probably going to break binary
> compatibility and is mostly about coding conventions, I would like to have
> some feedback before investing time.
Great! 

> The general idea is to create a playground project for automatic
> (de)serialization for Qt (not manual, i.e. overriding operators). The only
> stopper is container deserialization.
> To operate containers without staticaly knowing their types, one should be
> able to make conversions from QVariant containing a container to container
> of QVariants and vice versa.
> Seriazation is quite straightforward via QSequentialIterable and
> QAssociativeIterable. But deserialization is currently possible only by
> QMetaType::registerConverter. I think, that this is would be so nice to
> have an ability to create a container via QVariant from collection of
> QVariant instances without a need for custom converters.
> ~
> QList variantContainer;
> variantContainer.append(QVariant(123));
> variantContainer.append(QVariant(321));
> QVariant variant(QVariant::fromValue(variantContainer));
> QVariant containerVariant(variant.convert(qMetaTypeId >()));
> ~
You can be sure that the conversion from QList to QSequentialIterable 
will be successful, but the other way around is not given. QSequentialIterable 
can contain QVariants of different types. I'm curious what is the use case for 
the feature?

I think it could be implemented by extending:
https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qmetatype.h.html#2306
which registers conversion from a container to QSequentialIterable. You could 
add the opposite function. That way no binary compatibility would be broken 
nor major re-factoring would be needed.

> And so I have stumbled into a problem. QSequentialIterable  and
> QAssociativeIterable related code is scattered across  and
> . All related conversions are conveyed in templates, instead
> of
> https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.cpp#n
> 387 .
> I just don't feel, that further
> https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.h#n78
> 2 and
> https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qmetatype.h#n1
> 121 development
> is the way to go.
Well, it is a bit of a mess. Conceptually, conversion code should be in 
qmetatype.cpp/qmetatype.h. QVariant should use QMetaType to access / modify / 
create / convert instances of different types. The code is not well split 
because QMetaType class is a late addition, so as usual historical reasons 
:-). If you want to cleanup it a bit I would start on moving 
QSequentialIterable and QAssociativeIterable out of qvariant.h to own headers.

The fact that the conversion happens through QVariantValueHelperInterface in 
my opinion is a mistake, this code should be de-inlined as it is hard to 
extend it. 
> And so the question is: should I try to refactor sequential and associative
> iterators, so templates are used only to staticaly gather information about
> containers and conversions are made in qvariant.cpp, where they belong?
Sure, try, you can add me to review :-)

> It also would be nice to hear, if someone acknowledges this conversion
> feature to be of use.
Yeah, there are not so many users of QXXXIterable. So as long as we can keep 
cost of it low it is fine.

> Thanks for reading this far.

Thanks!
  Jędrek



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

Re: [Development] CMake branch

[Jedrzej Nowacki]

On Friday, March 22, 2019 9:58:33 AM CET Simon Hausmann wrote:
> Am 21.03.19 um 15:54 schrieb Tobias Hunger:
> 
> > My idea was to ask for merging wip/cmake after
> > https://bugreports.qt.io/browse/QTBUG-73925 (aka. "milestone 1"). At that
> > point
 the branch would be in a state where people can work on Qt (for
> > certain platforms) using cmake and do drive-by-contributions to cmake.
> > Right now it is more like working on CMake for Qt and doing
> > drive-by-contributions to Qt:-)>
> >
> >
> >> By doing the cmake work in a separate branch, we are keeping this hidden
> >> from
 everyone else. That was the right thing to do while we didn’t know
> >> if we want to go with it and what the structural implications of this
> >> change will be, but now we know, and it’s time to move this work into
> >> the mainline.
> > 
> > We have no decision from the Qt project yet. Submitting a patch for review
> > and
 getting that accepted would be such a decision:-) For this reason
> > alone I would very much welcome this proposal -- *if* we get volunteers
> > to help with keeping cmake up-to-date with qmake.
> >
> >
> >
> >
> > The wip/cmake branch is currently behind qt5/dev and we need to update it.
> > So if
 the Qt project decides to litter qtbase with CMakeLists.txt files
> > ASAP, then we will still need a while to send the actual patch for
> > review.
> >
> >
> 
> 
> Tobias' last paragraph is key here. For this proposal to be implemented, 
> a merge of wip/cmake with dev needs to be done, regardless. That works 
> needs to be done first. We need help.
> 
> 
> I like the overall idea of trying this out in dev - we should dare to do 
> this. If it doesn't work out and it slows everything down, then we can 
> still go back and branch off of dev. If it works out as planned and 
> yields more contributions, then we win. I think earlier last year we 
> never considered this even, but today the quality of the .pro file 
> converter has made this a possibility worth trying.
> 
> 
> It might be though that completing milestone 1 (QTBUG-73925) presents a 
> more sensible point of convergence where we could bring this into dev. 
> Mikhail, Jesus, what do you think?
> 
> 
> Simon

Hi,
 
  I'm supporting Mikhail' proposal and I'm probably a bit guilty of the thread 
too. As some of you know I'm not enthusiastic about any build system. I really 
think that there are too complex for the purpose. What I care about is 
shortening my development cycle and I can see how the cycle could be reduced 
with ninja. I could try to help with porting to cmake, but I have nothing to 
do in the wip branch. At the point in which cmake port works in at least on 
one platfrom with developer build I do not see reason to not have it in 
dev(*). 

  I'm also a bit afraid that we are making the same delivery mistake as with 
qbs. Everything is hidden behind an outdated feature branch. It requires quite 
a mental effort to actually look there. By looking there you need to be 
determined on working on the feature (there is nothing else there). 

  In addition seems that we go with a big bang approach, which worries me a 
bit. Could you explain me why the temporary goal is to have two parallel build 
systems? Why we can not port stuff one by one and allow qmake to call cmake and 
cmake to call qmake? For example why we can not already (*) require cmake to 
build tests, moc, plugins and others?

  There was also argument that we should not have cmake stuff in qt5 LTS. I do 
not understand it, to be honest. That is really an implementation detail of 
Qt. We can have some transition scripts so configure && make && make install 
somehow workflow works, but that is all.

(*) With assumption that we agree that cmake is the chosen one. I do not think 
that the port needs to be ready before accepting it. In my opinion it is 
enough to commit to it based on the state of the wip/cmake branch. So are we 
sure that cmake is the way to go? If yes then let's go to dev.

Cheers,
  Jędrek


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

Re: [Development] Continuous Integration for 3rd party projects using Qt

[Jedrzej Nowacki]

On Tuesday, March 19, 2019 7:55:53 AM CET Uwe Rathmann wrote:
> Hi all,
> 
> in the end all advice goes into the direction of using one of the
> standard services in combination with using my own brain when working on
> the code.
> 
> Unfortunately nobody pointed out a realistic way how a 3rd party project
> could make use of the infrastructure used by the Qt project nor did
> anyone seem to like this idea enough to think it through.
> 
> Anyway - thanks for all the valuable thoughts and links,
> 
> Uwe
> 

Hi,

 Coin is able to build and tests practically any qmake and >qt5.6 (soon qt5.9) 
based project. It has to be hosted on codereview.qt-project.org, there is 
limited support for git.qt.io or github.com (can not work as a gate keeper). 
There is no SVN support at all. Qt4 support would be a pain in general, 
because of many reasons.

  Qt project CI is for modules that closely follow Qt, including coding style 
as well as release cycle. It is not a general CI, it could be, as it is not 
that far from it, but it is not. There is an ongoing effort to simplify 
3rdparty modules builds ("Qt modules, API changes and Qt 6" 
https://lists.qt-project.org/pipermail/development/2019-January/035018.html), 
but even then I 
would not expect to build against anything older then the oldest LTS. The 
build system, platform configurations, dependencies are changing too quickly 
and all modules needs to follow.

Cheers,
  Jędrek


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

Re: [Development] On deprecating functions

[Jedrzej Nowacki]

On Tuesday, March 5, 2019 8:14:00 AM CET Lars Knoll wrote:
> One solution I thought about is to replace the QT_DEPRECATED(_X) macros with
> something that also contains the version (similar to QT_DEPRECATED_SINCE).
> Then the user could define how current he wants to be, and we could set a
> reasonable default going e.g. one LTS back.
> 
> So use something like
> 
> QT_WARN_DEPRECATED(5,13) void myDeprecatedFunction()
> 
> And expand it to wither QT_DEPRECATED or nothing depending on the version
> limit set.

I believe there is also an alternative of making something like that:

  QT_BEGIN_DEPRECATED_SINCE(5, 12, 123)
  ...
  QT_DEPRECATED void foo();
  QT_DEPRECATED void bar();
  ...
 QT_END_DEPRECATED_SINCE(5, 12, 123)


Begin and end of a block would conditionally disable and enable the 
deprecation warning.

I think that QT_WARN_DEPRECATED(5,13) idea is better, but the block version is 
a bit easier from scripting perspective.

Cheers,
  Jędrek


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

Re: [Development] CMake Workshop Summary

[Jedrzej Nowacki]

On Friday, February 22, 2019 7:18:36 AM CET Thiago Macieira wrote:
> But do note that our parallelism isn't that bad right now.

It is not bad, but it is not great either :-). For example one needs to _link_ 
QtCore before compilation on other things can be started, it is quite visible 
on an under-powered machines, where linking takes time. Similar, redundant 
synchronization point is on the module level.

Jędrek


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

Re: [Development] Allow to do parallel integration (was: Proposal: New branch model)

[Jedrzej Nowacki]

On Wednesday, January 30, 2019 1:55:41 PM CET Allan Jensen wrote:
> On Wednesday, 30 January 2019 13:38:46 CET Jedrzej Nowacki wrote:
> > On Wednesday, January 30, 2019 11:48:40 AM CET Allan Jensen wrote:
> > > On Wednesday, 30 January 2019 11:19:07 CET Edward Welbourne wrote:
> > > > Jedrzej Nowacki (30 January 2019 11:08)
> > > > 
> > > > > Mårten pointed out that we can check for conflicts up front. Not
> > > > > only
> > > > > against HEAD of the target branch, but also against all build
> > > > > branches.
> > > > > That is even nicer as there is no need to start a job that would
> > > > > likely
> > > > > to be rejected at the end.
> > > > 
> > > > That'll only find VC-level conflicts.
> > > > It's no help in finding the kinds of breakage that only testing
> > > > reveals.
> > > > It'll also sometimes lead to rejecting a change needlessly, because
> > > > the
> > > > already-integrating branch it conflicts with is about to fail its
> > > > testing.
> > > > Still, I guess restaging a little later can fix that ...
> > > 
> > > We could do speculative merging. Guess if the previous commit will merge
> > > on
> 
>  not, and stage the following commit based on that guess. Or stage two
> 
> > > versions of the next commit, one for success of the previous and one for
> > > failure. That latter would use 3x the VMs for 2x the throughput.
> > > 
> > > 'Allan
> > 
> > We could. In such case we do not allow regressions, but we waste ~50% of
> > speculative builds. I believe that would be much better accepting the
> > risks,
>  the throughput maybe N times higher, when N is count of parallel build
> 
> > branches. In the end reverts are just one click. Btw. after revert coin
> > will likely detect that the revision was build and it would just use
> > cached
> > results, so it may even avoid running tests.
> 
> At the current pass rates it would be a better speculation to assume that
> the other commits do not merge.
> 
> 'Allan

Not to my knowledge (last 7 days):

total   percentage
Passed 153 47.37%
Failed 147 45.51%
Cancelled 23 7.12%


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

Re: [Development] Allow to do parallel integration (was: Proposal: New branch model)

[Jedrzej Nowacki]

On Wednesday, January 30, 2019 11:48:40 AM CET Allan Jensen wrote:
> On Wednesday, 30 January 2019 11:19:07 CET Edward Welbourne wrote:
> > Jedrzej Nowacki (30 January 2019 11:08)
> > 
> > > Mårten pointed out that we can check for conflicts up front. Not only
> > > against HEAD of the target branch, but also against all build branches.
> > > That is even nicer as there is no need to start a job that would likely
> > > to be rejected at the end.
> > 
> > That'll only find VC-level conflicts.
> > It's no help in finding the kinds of breakage that only testing reveals.
> > It'll also sometimes lead to rejecting a change needlessly, because the
> > already-integrating branch it conflicts with is about to fail its testing.
> > Still, I guess restaging a little later can fix that ...
> 
> We could do speculative merging. Guess if the previous commit will merge on
> not, and stage the following commit based on that guess. Or stage two
> versions of the next commit, one for success of the previous and one for
> failure. That latter would use 3x the VMs for 2x the throughput.
> 
> 'Allan

We could. In such case we do not allow regressions, but we waste ~50% of 
speculative builds. I believe that would be much better accepting the risks, 
the throughput maybe N times higher, when N is count of parallel build 
branches. In the end reverts are just one click. Btw. after revert coin will 
likely detect that the revision was build and it would just use cached 
results, so it may even avoid running tests.

Cheers,
  Jędrek



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

Re: [Development] Allow to do parallel integration (was: Proposal: New branch model)

[Jedrzej Nowacki]

On Wednesday, January 30, 2019 11:19:07 AM CET Edward Welbourne wrote:
> > Mårten pointed out that we can check for conflicts up front. Not only
> > against HEAD of the target branch, but also against all build branches.
> > That is even nicer as there is no need to start a job that would likely
> > to be rejected at the end.
> 
> That'll only find VC-level conflicts.
> It's no help in finding the kinds of breakage that only testing reveals.

Of course. That is exactly what I'm proposing. 

Cost: CI would allow breakages caused by patches that are being integrated in 
parallel. 
Gain: CI would allow running many parallel integrations. 

> It'll also sometimes lead to rejecting a change needlessly, because the
> already-integrating branch it conflicts with is about to fail its testing.

We have that already, you can not stage if your change conflicts with changes 
that are being integrated. Gerrit gives you a nice and complex message. Maybe 
it will work out of the box, with multiple build branches. I do not know. Some 
research is needed.

> Still, I guess restaging a little later can fix that ...
Exactly. Hopefully less restaging. As cherry on top it may increases chances 
that the content sha1(*) optimization kicks in, so re-staging may be faster.

Cheers,
  Jędrek

(*) Coin works on the content sha1 level not on the commit sha1. That way 
commit message change or different commit order is irrelevant from it's 
perspective and it can re-use caches. 


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

Re: [Development] Allow to do parallel integration (was: Proposal: New branch model)

[Jedrzej Nowacki]

On Wednesday, January 30, 2019 10:41:02 AM CET Jedrzej Nowacki wrote:
> Cheap (a.k.a reasonably fast to implement) proposal:
> - Stage button would create a stage branch as currently (through cherry-pick
> 
 on top of target branch)
> - 3-5 minutes old stage branch would changed to be a build branche and all 
> patches in it would be changed to "integrating" state. CI would start
> testing the build branch. At that time a new stage branch may be created.
> As opposite to now, multiple build branches may be tested in parallel.
> - Once a build branch testing passed we cherry-pick / merges (depends what 
> gerrit does) changes on top of the target branch, in case of conflicts we
> mark it as failed.

Mårten pointed out that we can check for conflicts up front. Not only against 
HEAD of the target branch, but also against all build branches. That is even 
nicer as there is no need to start a job that would likely to be rejected at 
the end.

Cheers,
  Jędrek


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

[Development] Allow to do parallel integration (was: Proposal: New branch model)

[Jedrzej Nowacki]

On Friday, January 25, 2019 11:08:52 AM CET Lars Knoll wrote:
> To me this means we need to seriously rethink that part of our CI system,
> and ideally test changes (or patch series) individually and in parallel. So
> maybe we should adjust our CI system that way:
> 
> * test changes (or patch series) individually
> * If they pass CI merge or cherry-pick them into the branch
> * reject only if the merge/cherry-pick gives conflicts
> 
> This adds a very small risk that two parallel changes don’t conflict during
> the merge/cherry-pick process, but cause a test regression together. To
> help with that, we can simply run a regular status check on the repo. If
> this happens the repo will be blocked for further testing until someone
> submits a fix or reverts an offending change, which is acceptable.
> 
> Another advantage is that this would pave the road towards a system where CI
> testing happens before human review, so we can in the longer term avoid
> duplicated review/approval work.

Hi,

 I do agree with it. Personally, I'm convinced that we are doing CI gate-
keeping in a wrong way. CI is about balancing costs vs. gains. We can not test 
everything, we should find as many as possible bugs, while running in 
reasonable time without using too much resources. That is the function to 
optimize.

 We really should test things in parallel. The risk of conflicts / regression 
caused by parallel integration in project as big as qt is minimal. One can be 
even proactive and not stage changes while other similar ones are integrating. 
While broken repository state is bad, it is also easy to detect; nothing 
integrates because of one test, which is not known to be flaky 
(testrestults.qt.io/grafana...). 

Cheap (a.k.a reasonably fast to implement) proposal:
- Stage button would create a stage branch as currently (through cherry-pick 
on top of target branch)
- 3-5 minutes old stage branch would changed to be a build branche and all 
patches in it would be changed to "integrating" state. CI would start testing 
the build branch. At that time a new stage branch may be created. As opposite 
to now, multiple build branches may be tested in parallel.
- Once a build branch testing passed we cherry-pick / merges (depends what 
gerrit does) changes on top of the target branch, in case of conflicts we mark 
it as failed.

Advantages:
 - changes are tested in smaller batches => smaller chances to fail
 - we can use hardware in a more efficient way => more code integrated per hour
 - fairly easy to implement => we would not need to wait for it to happen 
years
- that would be a step forward in to direction of testing before reviewing

Disadvantages: 
- risk of breakages going through CI 
- someone work needs to be done to enable it

Cheers,
  Jędrek


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

Re: [Development] Qt modules, API changes and Qt 6

[Jedrzej Nowacki]

On Sunday, January 27, 2019 11:47:04 AM CET Harri Porten wrote:
> On Sat, 26 Jan 2019, Olivier Goffart wrote:
> > I think the "monorepo" is clearly a good approach. And git is evolving
> > with
> > shadow clones and partial checkout. LLVM/Clang recently choose the
> > monorepo
> > approach as it moves to git.
> > 
> > Of one problem is that this will make CI integration slower because each
> > CI
> > run now have to test both qtbase and qtdeclarative tests.
> 
> I've started to develop sympathy for "monorepos" during the last years. To
> counter often expressed fears like excessive build and test times one has
> to point out:
> 
> Bigger (or even single) repositories do NOT mean
> 
>- monolithic builds and test runs
>- monolithic packaging
> 
> Developers and packagers are free to model logical segements according to
> their needs.
> 
> Harri.

Hi,
 
  Personally, I also do like the idea of monolithic repo, while keeping 
modularization on the logical / build level. In our current state I see two 
major problems:
- our build is quite monolithic in practice. For example qtbase always needs 
to be build. CI currently caches builds on repository level (caches results of 
make install) with monolithic repository the optimization would need to be 
reconstructed on the build level. Conceptually it is good, but someone would 
need to do the work.
- as a consequence of a partial build, the repository may be in a broken 
state, for example not compiling. It can be solved by time based world 
rebuilding and tagging known good revisions, but some policies would need to 
be created.

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Monday, January 28, 2019 2:38:44 PM CET Robert Loehning wrote:
> Am 28.01.2019 um 14:09 schrieb Jedrzej Nowacki:
> 
> > On Friday, January 25, 2019 3:23:36 PM CET Robert Loehning wrote:
> > 
> >>> Testing whether the bug that I’m fixing exists in dev or not is part of
> >>> the drill of fixing bug, isn’t it? Why would you spend time on fixing
> >>> something in 5.12 without checking whether the issue is still present
> >>> in
> >>> the latest codebase? Perhaps the issue has been fixed already, just
> >>> without the author considering it relevant for 5.12 (perhaps for good
> >>> reasons).
> >> 
> >> Why would somebody who maintains a project on Qt5 but made the decision
> >> to not migrate it to Qt6 care about fixing the latter?
> >>
> >>
> >>
> >> Cheers,
> >> Robert
> > 
> > 
> > Project that is not being updated is not maintained. Not maintained
> > projects
 should not take part of the mainstream.
> > 
> > Cheers,
> > 
> >Jędrek
> > 
> > 
> > 
> 
> 
> I mean an external project which is based on Qt, like some commercial 
> application. Say they decided - for good or bad reasons - that they will 
> not migrate to Qt 6, but they require a fix in Qt 5. They even provide 
> this fix, but why would they care about making it work in Qt 6?
> 
> Cheers,
> Robert

We have the same problem right now, just in the opposite direction. One want 
to fix version 5.9, why the person should help with merging and solving 
problems in 5.12? At least the problem would be visible in gerrit as an not 
staged change.

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Friday, January 25, 2019 2:17:15 PM CET Edward Welbourne wrote:
> On 25 Jan 2019, at 10:10, Simon Hausmann 
mailto:simon.hausm...@qt.io>> wrote:
> >> I think it's worthwhile to develop the tooling to automate
> >> cherry-picking. That tooling is something that is perhaps best tried
> >> on a release branch first.
> >> 
> >> I do quite like what Allan suggested: We could try the cherry-pick
> >>
> >>the other way around. Volker, Lars, Thiago etc. surely remember the
> >>p4i script we used to have when we were using Perforce. Imagine that
> >>with more automation.
> 
> Lars Knoll (25 January 2019 11:08)
> 
> > The risk with this is that we might end up having fixes in a stable
> > branch that don’t make it do dev for various reasons, so it’ll regress
> > in the next minor release.
> 
> It should be fairly trivial to ensure we tag the cherry-picks in such a
> way that some routine script can alert relevant folk to ones that
> haven't been sorted out within a month, or before the next release on
> the branch they targeted.  I think this is less of a reason to worry
> than you suppose.
> 

Actually, I share the concern about regressions, if we turn the cherry-pick 
direction. Yes, we can detect such situations, but it is not given that anyone 
would act on it. What if an author is not responding or not doing anything 
about the dev cherry-pick? Who will volunteer to fix the situation? What if, it 
is actually hard task and it can not be done during a release time window?

I really prefer a system that automatically tries to not regress. I believe in 
transparency; maintenance of stable branch is a cost and cherry-pick from dev 
to stable shows the cost.

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Friday, January 25, 2019 9:25:16 AM CET Simon Hausmann wrote:
> I'm somewhat attracted to the proposed model, in conjunction with automation
> and by treating Qt6 differently.
>  
> However Allan's last point is what sticks to me most, the load on the CI and
> the resulting impact on productivity:
> 
> If all it would take to get changes distributed is a cherry-pick, then I can
> totally see how this can fly. However with a blocking CI and the rate of
> flakyness we are experiencing at least in qtbase, I think this carries a
> high risk of slowing down development.

Bigger then the current merging strategy? 

>  (...)
> It would seem that quite a bit of
> tooling needs to be developed first anyway?

Nah the cherry-picking bot would be reasonably easy. Sanity bot has the option 
to warn already built-in, although I haven't looked how to enable it for all 
non dev branches. Migration itself requires some one time scripting and 
backups, I guess it would be rather about logistics and synchronization, then 
technical challenges.

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Thursday, January 24, 2019 10:29:13 PM CET Ville Voutilainen wrote:
> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann  wrote:
> > I would see the biggest long term impact with the massive amount of cherry
> > picks from dev to qt6 over a long period of time.
> > 
> > Git rerere works locally, so it doesn’t help in this setup I think.
> 
> Completely seriously, without any preference to either branching
> approach: aren't we going to be in some sort of trouble
> with the qt6 branch anyway, no matter what we do? 

I agree. There is also feature based approach, which would make code uglier... 
All in all we will pay some price for keeping Qt6 and Qt5 in parallel.

> But I don't see how going from merge-forward (except also
> merge-backward sometimes) to cherry-pick-backward
> (except also cherry-pick forward, or kinda sideways to qt6, and maybe
> sometimes merge in some direction) is going
> to help us with qt6. These matters seem orthogonal.
> 
> Qt6 and dev are going to diverge. Drastically, eventually. I don't
> know how to solve that. A new branching policy
> is not going to help with that.

It will simplify Qt6 mainly by :
 - distribution of conflict resolution
 - Qt6 development will not be delayed by waiting for merges to happen, 
because some refactoring needs to be done in more stable branches (for example 
tests)

I agree, the branching model is not a silver bullet, it will be ugly anyway, 
let's not make it very slow in the same time :-)

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Friday, January 25, 2019 11:50:55 AM CET Eike Ziller wrote:
> Note that this risk exists partially even if fixes are first pushed into dev
> and then from dev directly to multiple “stable” branches.
> 
> Fix goes into dev.
> Fix is cherry-picked into 5.9 without issues.
> Fix is cherry-picked into 5.12 and for whatever reason there are issues with
> that.
> 
> There is a risk that the bug will not be fixed in the next (or any) 5.12
> release even though it already is fixed in 5.9. Granted, it will be fixed
> in 5.13 again. This is also not ideal and requires release management to
> keep track of these changes to avoid it. (Some of this risk exists also for
> 5.12.x branch vs 5.12 branch, if we directly pick from dev to 5.12.x)

Yes, It may happen, but as you said in the infinity it will be fixed. Tracking 
should be quite easy, it is just a gerrit query; give me all 1 month old, open 
changes for branch 5.12.

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Friday, January 25, 2019 1:30:52 PM CET Shawn Rutledge wrote:
> > On 25 Jan 2019, at 09:43, Martin Smith  wrote:
> > 
> > 
> >> It is the absolute exception that a change goes into qtbase on first
> >> attempt.
> 
> > 
> > But many rejections have nothing to do with any change at all. I often
> > submit documentation-only changes to QtBase, and they often get tested
> > alone, with no other changes. They still get rejected multiple times
> > because test X fails this time and test Y fails next time, despite the
> > fact that my change only fixes typos in the qdoc comments. Sometimes
> > there is a compiler failure too, which is not caused by the change.
> 
> Could we simplify testing for some types of patches?  E.g. if the patch only
> touches documentation, don’t run tests, except those that involve building
> docs, if we have any of those.  (Even building the code is dubious in that
> case, as long as the bot that decides that it’s a doc-only patch actually
> verifies that the only changes are inside comments.)  If it only touches
> widgets, some time-consuming and failure-prone tests like network tests
> could be skipped.  And so on.
 
Sure, please implement it  :-). It has to be maintained on the build system 
level, so one can start already. CI can provide some magic parameters to the 
build system and then the build system can use whatever heuristic are needed 
when running "make check". I wouldn't mind that option even for local 
development.

This is out of scope for branch model discussion, for my taste :-)

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Friday, January 25, 2019 11:08:52 AM CET Lars Knoll wrote:
> This adds a very small risk that two parallel changes don’t conflict during
> the merge/cherry-pick process, but cause a test regression together. To
> help with that, we can simply run a regular status check on the repo. If
> this happens the repo will be blocked for further testing until someone
> submits a fix or reverts an offending change, which is acceptable.
> 
> Another advantage is that this would pave the road towards a system where CI
> testing happens before human review, so we can in the longer term avoid
> duplicated review/approval work.

Yes, yes, yes, pretty please :-)


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Thursday, January 24, 2019 2:35:51 PM CET Allan Sandfeld Jensen wrote:
> We can't integrate multiple changes to the same branch in parellel. So you
> can't start using more resources to speed things up. (9 women to have a
> child in 1 month) The only way to speed up CI integration is to be merging
> to different branches, that way we CAN have multiple integrations running
> in parallel.

Well, I can use more resources. We can build on stronger machines CPU limits 
are quite arbitrary. We could build tests during build phase (it means more 
CPU power, Aapo is currently pushing the task forward). In the end we could 
execute tests on multiple machines (it is an old idea, that was just down-
prioritized).

/side note:  The fact that we do not run multiple integration in parallel for 
one branch is super annoying to me, it is just waste of time, we should change 
it. As far I know we are doing it only to avoid potential breakages caused by 
two concurrent change, in my opinion cost / gain ratio is terrible. Again that 
is another discussion.

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Thursday, January 24, 2019 7:46:35 PM CET Sergio Ahumada wrote:
> On 24.01.19 14:10, Edward Welbourne wrote:
> > Automated cherry-picking implies various complications that we haven't
> > fully explored; whereas merges have some well-established reliable
> > properties that avoid many of those complications.  Engineers prefer
> > what's known, from experience, to work over things that sound like they
> > might.  OTOH, as Ville points out, other projects do use cherry-picking;
> > so perhaps we need more information from such projects,
> 
> I have seen this implemented, similar to what Jedrek proposed, but the
> decision where to cherry pick is in JIRA, not via git annotations/marks.
> 
> This requires the Release Manager to keep an eye on which changes have
> not being propagated to all branches, though.
> 
> fully automated process, the fix is pushed to the oldest branch (5.12)
> and then propagated to newer versions (5.13, dev, etc). Change is
> automatically cherry-picked, updated the commit message, uploaded to
> gerrit, automatic Code-Review+2, automatic stage, automatically merged
> if CI passes.
> 
> propagation rate failure is around 20% of, mostly due to:
> - merge conflicts (will happen, for sure)
> -- genuine merge conflicts
> -- change was already cherry-picked manually
> -- dependencies missing
> - ci failures
> -- mostly due to infrastructure issues
> -- ci does not know how to handle dependencies
> 
> advantages:
> - when it works, everybody is happy
> - pass rate is very high (around 80%)
> - one can run git-cherry-pick -n and add additional info in the commit
> message
> - can be tuned up to exclude some changes from being propagated (the
> bot, not git-cherry-pick itself)
> 
> disadvantages:
> - most developers don't know how to handle the propagation failures
> -- I already moved on and am working on something else, do you want me
> to switch to '5.19' to fix a change I did in '5.12' ? oh, and it failed
> in '5.18' as well? why don't you do merges instead and leave alone?
> [true story :-)]
> - change can pass the CI and found to be problematic later on
> -- oh, I need to fix my change in 5 branches now? [Gerrit 2.14 has a
> cherry-pick button in the UI now, so this is not a problem with that
> version]
> - automated cherry-pick process/bot/script has to be maintained
> -- one change not merged might lead to lots of changes to fail with
> merge conflicts, staying open in gerrit forever
> -- hey, can you add intelligence to the bot so it know how to merge the
> open changes once the dependency is merged?
> -- hey, can you add intelligence to the bot so it can cherry-pick them
> in the right order?)
> - yes, git-cherry-pick does weird things. I have seen it cherry-picking
> the same change twice without problems (same line twice in the file, I
> think I was an include guard that compiled but behaved weirdly, or similar)
> 
> my 2€

Thank you for the story, do I get it correctly that the most of problems are 
social and global flakiness of the system?

Cheers,
  Jędrek



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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Friday, January 25, 2019 3:23:36 PM CET Robert Loehning wrote:
> > Testing whether the bug that I’m fixing exists in dev or not is part of
> > the drill of fixing bug, isn’t it? Why would you spend time on fixing
> > something in 5.12 without checking whether the issue is still present in
> > the latest codebase? Perhaps the issue has been fixed already, just
> > without the author considering it relevant for 5.12 (perhaps for good
> > reasons).
> Why would somebody who maintains a project on Qt5 but made the decision
> to not migrate it to Qt6 care about fixing the latter?
> 
> Cheers,
> Robert

Project that is not being updated is not maintained. Not maintained projects 
should not take part of the mainstream.

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Thursday, January 24, 2019 3:18:59 PM CET Kari Oikarinen wrote:
> On 24.1.2019 16.15, Edward Welbourne wrote:
> 
> > Kari Oikarinen (24 January 2019 15:02)
> > 
> >> The rest of the paragraph talks about a situation where we will have two
> >> stable
 branches alive at the same time. Typically we don't, because
> >> once 5.x+1 is created, 5.x is closed.
> > 
> > 
> > Not quite: once 5.x+1 is *released*, 5.x (if not LTS) is closed
> > (unless we have a pressing reason to release another 5.x.y).
> > So, in the interval between 5.x+1 branching and releasing,
> > we have three branches.
> 
> 
> Right, so typically we indeed have two stable branches open. Thanks for 
> correcting me.
> 
> 
> > 
> > 
> >> But 5.12 is an LTS version, so it will still stay open.
> > 
> > 
> > Indeed.
> > 
> > 
> >> But at what point (under current process) would be switch it to
> >> cherry-pick only
 mode? I don't remember when it happened for 5.9. It
> >> could be when 5.13 is created and then there would be no release blocked
> >> by waiting for a merge.> 
> > 
> > We switch to cherry-picking into 5.12 when 5.14 is created.
> > See QUIP-5,
> > * https://quips-qt-io.herokuapp.com/quip-0005.html
> > 
> > So creation of 5.14 switches our merge pattern from 5.12->5.13->dev
> > to 5.13->5.14->dev and the 5.14 release (probably) closes 5.13.
> > Again, we could of course change that.
> 
> 
> Yes, but I was attempting to describe the current approach and messed it
> up.
 
> -- 
> Kari


Well, you are still right about the fact that 5.x.z is not in cherry-pick mode 
always. How it can happen that people involved in the process aren't always 
correct about branching model.  That is simply too complex to follow.

Btw. it also may add one merge to all merges count I mentioned before.

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia czwartek, 24 stycznia 2019 13:33:28 CET Allan Sandfeld Jensen pisze:
> On Donnerstag, 24. Januar 2019 13:27:41 CET Jedrzej Nowacki wrote:
> > Dnia środa, 23 stycznia 2019 22:04:16 CET Allan Sandfeld Jensen pisze:
> > > On Mittwoch, 23. Januar 2019 16:51:10 CET Jedrzej Nowacki wrote:
> > > >   Proposal in short: let's use cherry-pick mode everywhere.
> > > >   
> > > >   All(**) changes would go to dev. From which they would be
> > > >   automatically
> > > > 
> > > > cherry-picked by a bot to other branches. The decision to which branch
> > > > cherry-
> > >  
> > >  pick, would be taken based on a tag in the commit message. We
> > >  
> > > > could add a footer that marks the change risk level as in quip-5
> > > > (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example
> > > > "dev",
> > > > "stable", "LTS". By default everything would be cherry-picked to qt6
> > > > branch
> > > > unless "no-future" tag would be given. Of course we can bike-shed
> > > > about
> > > > the
> > > > tag names.
> > > 
> > > I don't see any advantage to this what so ever. The same amount of work
> > > and
> 
>  refactoring needs to be done, all you have done is made development
> 
> > > more prone to human error, and fixes less likely to reach their intended
> > > target, and made getting point releases out on time harder as they need
> > > to go through more steps before they have all their patches in.
> > > 
> > > 'Allan
> > 
> > It is hard to answer this because you have forgotten to write why you
> > think
> 
>  that development would be more error prone or fixes less likely to reach
> 
> > the destination or more steps would be involved in releasing. So I will
> > try
> > shooting in the dark :-)
> > 
> > The current merging strategy involves couple of people, one merge master
> > and a
> 
>  random reviewer that looks at conflicts if there are any. Usually it is
> 
> > not even close to quality level we have for single patches in which we
> > have
> > more reviewers and gerrit shows the real diff. In practice we assume that
> > no conflicts == good merge.
> > 
> > Fixes are less likely to hit target branches, true, but only if nobody
> > cares.
> 
>  Mark that a fix can magically disappear during broken mere, nobody
> 
> > will see it. The proposed solution allows at least track such cases.
> > 
> > Releases branches already use cherry-pick mode so from that perspective
> > there
> 
>  is no big changes, the only one is the origin branch from which the
> 
> > cherry- pick should happen.
> 
> Yeah, this was no the best of comments on the issue. But I believe I wrote
> my objections elsewhere:
> - Cherry-picks are more error prone in git than merges and requires manual
> intervention more frequently

Yes, they are in some ways, I think I managed to not hide them in the 
proposal. I believe that the load distribution, the fact that more people can 
handle issues, reduction in bus factor, ability to solve problems in parallel 
with a significantly smaller context/scope and transparency of the process 
overweight the risks.

In addition we may write tooling, that helps us to detect problems, like for 
example gerrit change hanging in a limbo for too long, because all of the data 
would be there. 

> - Even if we accept the always and instantly cherry-pick model, there is no
> reason to push to dev, continuing to push to the same branches as now could
> achieve all the same things with less room for error (because where it is
> supposed to be merged to is both implicit and unambigious)

I mentioned that before. Cherry-picking from stable to dev means that in case 
of an error we have a regression. In my opinion it is worse, then accidentally 
not having a fix for something that was broken forever in an older branch.

> - By having all commits go to the same branch you make that branch
> overloaded, and will break our CI even more than it already is.

I will answer that in other part of thread, as I believe it deserve a subtopic 
on it's own.

> - I don't see making it harder to fix bugs in the stable branch as a
> benefit.

Why harder? Conflicts rate is more or less the same, they will be just resolved 
by a different person. So I wouldn't call it harder just the maintenance cost 
would be more visible / moved to the author.

Cheers, 
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia czwartek, 24 stycznia 2019 14:23:21 CET Kari Oikarinen pisze:
> We're also using cherry-picking ourselves in LTS branches. At least older
> ones,
 5.12 is not at that mode yet. As far as I know it has been working
> well. 
> Since the problems with cherry-picking come up as the changes pile up and
> concurrent development happens, those are largely avoided in the older
> branches.
 
> A less ambitious change to our current process could be moving branches
> into
 cherry-picking mode earlier. That would limit the count of currently
> active branches that we need to merge between. Of course the effects of
> such a change would be much smaller also. But just to mention it because I
> don't think anyone has mentioned it yet.
> 
> -- 

Good point, we could move branches to cherry-pick mode earlier. So for example 
if we have qt6, dev and stable (whatever the number is) we would have "only" 
two merges from stable to qt6. Or we could keep merges from dev to qt6 for a 
little longer. Personally I would go all for cherry-pick mode instead to 
simplify the model, but I agree that it is still better then what we have now.

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 23:05:17 CET Allan Sandfeld Jensen pisze:
> More than that. Once you have had cherry-pick only for a while git will be
> unable to find useful common ancestors for the changes, and will be unable
> to do smart three-way merging of cherry-picks, increasing the number of
> conflicts that needs to be resolved manually while decreasing the useful
> information git can give you (no more useful three-way diff).
> 
> 'Allan

Good point, that is a risk. Question is how big it is. Does it really affect 
us, as old branches over time should be modified less and less. Are there 
tooling like git rerere able to help us?

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model (part: new contributors)

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 18:09:31 CET Alex Blasche pisze:
> > - simpler for new contributors, always push to dev
> 
> Really? Me being the new guy wanting to fix a bug in 5.12 need to magically
> know that I have to push to dev and know about a magic cherry-pick logic
> and a magic tag in the commit log. Right now I need to know I want to fix
> in 512 and push to it. Also the current model does not bother the new guy
> with myriads of potentially following cherry-picks which may require a
> larger commitment than he is willing to give. 

Really, at least that is my latest experience, when I contributed a fix to 
python standard library. I was trying to understand the branching model just 
to read that I should not bother and push stuff to master, there it was the 
reviewer responsibility to cherry-pick the change to other branches based on 
the content. I have to admit that I was impressed how easy is to make the first 
time contribution to the project. In our case, gerrit allows you to change 
commit message online in the browser, that makes reviewing / re-targeting  
task easier and less prone to errors (case of accidental re-push to a wrong 
branch after bot moving it). You are assuming that the contributor knows that 
the fix has to be and can be in 5.12. Well, that may be the case, some will 
have no clue and be fine with any future release. 

If a new contributor pushes to a wrong branch sanity bot would warn and allow 
you to move it to dev.

> The entire bot logic section below is another non-implicit logic.

What do you mean? As you do not target 5.X.Z, I would call it quite implicit 
:-).

Cheers,
  Jedrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 21:47:16 CET Edward Welbourne pisze:
> On Wednesday, 23 January 2019 11:01:53 PST Volker Hilsheimer wrote:
> >> I think that’s fine. What’s much worse is having a fix in 5.12 and not
> >> knowing how to deal with the merge conflicts into dev. That means dev
> >> might
> >> regress, unless whoever authored the change is willing to spend time on
> >> making it work. In the end, if contributors can’t own their changes for
> >> all
> >> various branches of Qt, then I much prefer for them to own the changes at
> >> least for dev. And with Qt 6, this will become a much bigger problem.
> 
> Thiago Macieira (23 January 2019 20:10)
> 
> > The problem is I can turn this around and say that we introduce
> > regressions
> > into the older branches due to an improper cherry-pick that didn't
> > conflict.
> and *that* is a concern that does bother me.
> Of course, it's got to pass integration, as well as not conflict,
> but that doesn't guarantee it hasn't broken something.

Of course, but it is not a regression to the current system, we have the 
problem currently, right? We can introduce a regression in a release branch by 
merging and cherry-picking without conflicts. On the other hand logic that 
doesn't apply cleanly has a higher chances of introducing bugs and therefore 
higher chance of causing release problems. These changes are more visible in 
gerrit as opposite to somehow opaque merges. So in my opinion it is an 
improvement.

Cheers,
  Jędrek




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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia czwartek, 24 stycznia 2019 10:24:57 CET Allan Sandfeld Jensen pisze:
> On Donnerstag, 24. Januar 2019 10:11:35 CET Volker Hilsheimer wrote:
> > More people working and building against dev helps keep dev more stable
> > (by
> > virtue of discovering breakage sooner), and the proposal encourages more
> > people to work on dev. That can be a good thing.
> 
> No,  it will overload the CI by having all integrations happen on the same
> branch, instead being able to integrate multiple branches at once.

It will overload in what way? Yes, in total we would have more integrations. 
If you look into the statistics (https://testresults.qt.io/grafana/d/
00024/telegraf-host-metrics) you can see that we have some free resources. 
In general we should not really cross load of 60, but most of the hosts are on 
significantly lower load. I would be more concerned about flakiness, as it 
means 
that we run more tests, but that is something that we need to fix no matter 
what.

> > Either way, nothing in the proposal prevents us from developing and push a
> > fix for 5.12, and then develop a different fix for dev that we don’t
> > cherry
> > pick into 5.12 or other stable branches. This should be an exception, used
> > in urgent situations where indeed we can’t wait. For those cases, there’s
> > no merge conflict in the first place in the new model (because there’s no
> > merge).
> 
> It is still doing merging the wrong way for no good reason. Even if cherry-
> picking itself wasnt a bad idea. You could just as well commit to the stable
> branch first and then cherry-pick it to the other branches. That way there
> would be no need for cryptic annotations, the branches to pick to would be
> implicit from where the patch first landed. Or even better, you could
> perform a merge to dev on every single commit to the stable branch, or even
> better, only create a merge if there are conflicts, so we don't overload
> the CI on dev.
> 
> 'Allan

If you cherry-pick the opposite way, the risk of regression is; higher, 
because of one time contributions (I'm using 5.9 I do not care about other 
releases, so I will not solve the merge conflicts or baby sit the changes) or 
because of lack of interest (oh, that is simply re-write I will not do it) or 
because just a mistake (oh it is still in my gerrit dashboard). In my opinion 
regressions are much worse then, a missing fix in an older branch.

Cheers,
  Jędrek



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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 22:09:30 CET Allan Sandfeld Jensen pisze:
> On Mittwoch, 23. Januar 2019 21:42:35 CET Edward Welbourne wrote:
> > Jedrzej Nowacki wrote:
> > >>  Advantages:
> > >>  - no waiting for merges, a fix can be used right away after
> > >>  
> > >>integration
> > >>  
> > >>  - faster propagation of fixes targeting all branches, as there are
> > >>  
> > >>no merges of merges
> > 
> > Alex Blasche (23 January 2019 18:09)
> > 
> > > This is pure speculation because you potentially triple (or worse) the
> > > amount of individual patches requiring a merge in gerrit when you
> > > consider that you want to at least merge to 5.9, 512, dev and qt6. I
> > > don't see this prediction come true.
> > 
> > Well, as soon as it hits dev, the patch is cherry-picked to every branch
> > that its footer says it belongs in.  Those branches where all goes well
> > see it one integration later.  Each branch that has a conflict needs
> > that resolved before we get to that second integrtion.  Contrast this
> > with a 5.12 -> 5.13 -> dev chain of merges, where dev doesn't get the
> > change that landed in 5.12 (even if that change could land in dev
> > without conflict) until
> > 
> >  * there's been some delay between their change being accepted in 5.12
> >  
> >and the next merge-bot run
> >  
> >  * everyone who made change to 5.12 that conflicted on merging to 5.13
> >  
> >has advised Liang on how to resolve their conflicts
> >  
> >  * we've got the result through integration into 5.13
> >  * everyone who's made changes to 5.13 or (as possibly just amended in
> >  
> >merging) 5.12 that conflicts with anything in dev has again advised
> >how to resolve their conflicts
> >  
> >  * and we've got the result through a second integration, into dev.
> > 
> > When nothing but the change being considered has a conflict along
> > the way, that's twice as long; and any change to an upstream branch,
> > that does have a conflict, introduces delay for all the other changes
> > that landed in that branch, even if they don't have conflicts.  In the
> > middle of summer, when lots of folk are away on holiday, getting help
> > with resolving conflicts isn't easy - the folk who know those commits
> > won't be back for a month - and all changes, no matter how urgent, get
> > stuck behind any conflict we can't work out how to resolve.
> > 
> > So no, Jedrzej's claim is not *pure* speculation; it's at least quite a
> > lot adulterated with reasons to believe that many changes would, under
> > his scheme, propagate to all branches they're destined for sooner than
> > happens with our present scheme.
> 
> No, it is speculation, and it optimizing the least important case: bug-fixes
> in dev. Dev is the branch that can wait the longest to get a bug-fix, the
> stable branch is the branch that need it the most urgent. And fixing a bug
> in 5.12 now means you first fix it where you need it (5.12), then rewrite
> it for dev, then resolve the inevitable conflict back so it can be merged,
> all waiting for bots and release teams to stumple into the issues and
> delaying the next 5.12.x release.
> 

First, I do not agree that dev is less important. Dev is the base for all 
future releases. Even if a current release is broken in some way, the next one 
should not be. We can not focus on short term only.

Typical use case I have with bug fixing in dev is when I develop a feature and 
I see let's say a memory leak in the code that I'm modifying or somewhere 
around. With the merge model I have four options now:
1. Pretend that I haven't seen it
2. Make a fix in LTS and develop my feature separately, counting on the merge 
master to resolve conflicts
3. Do the fix only in dev
4. Make a fix in LTS and wait for all merges before I continue with the feature
If it is a memory leak then it is not as bad as memory corruption and crashes, 
as at that point I can not use approach 2. Option 1 and 3 are not great from 
QA perspective. Option 4 is slow and kills motivation for development.

Last, but not least. The release branches are already in cherry-pick mode, so 
again it is not different, amount of conflicts is the same, true one needs to 
solve them earlier,  but on the other hand you can prepare the conflict 
resolution in parallel, while waiting for the integration. In your example you 
picked an easy target, but try the same with 5.13 and case of a fix targeting 
LTS. With the current model you need one merge (5.12 -> 5.13) and then one 
cherry-pick (5.13 -> 5.13.x). Of course you could cherry-pick from LTS 
directly to the release branch, but then you are acknowledge that merges are 
hurting us in terms of release speed. 

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 22:04:16 CET Allan Sandfeld Jensen pisze:
> On Mittwoch, 23. Januar 2019 16:51:10 CET Jedrzej Nowacki wrote:
> >   Proposal in short: let's use cherry-pick mode everywhere.
> >   
> >   All(**) changes would go to dev. From which they would be automatically
> > 
> > cherry-picked by a bot to other branches. The decision to which branch
> > cherry-
> 
>  pick, would be taken based on a tag in the commit message. We
> 
> > could add a footer that marks the change risk level as in quip-5
> > (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example "dev",
> > "stable", "LTS". By default everything would be cherry-picked to qt6
> > branch
> > unless "no-future" tag would be given. Of course we can bike-shed about
> > the
> > tag names.
> 
> I don't see any advantage to this what so ever. The same amount of work and
> refactoring needs to be done, all you have done is made development more
> prone to human error, and fixes less likely to reach their intended target,
> and made getting point releases out on time harder as they need to go
> through more steps before they have all their patches in.
> 
> 'Allan


It is hard to answer this because you have forgotten to write why you think 
that development would be more error prone or fixes less likely to reach the 
destination or more steps would be involved in releasing. So I will try 
shooting in the dark :-)

The current merging strategy involves couple of people, one merge master and a 
random reviewer that looks at conflicts if there are any. Usually it is not 
even close to quality level we have for single patches in which we have more 
reviewers and gerrit shows the real diff. In practice we assume that no 
conflicts == good merge.

Fixes are less likely to hit target branches, true, but only if nobody cares. 
Mark that a fix can magically disappear during broken mere, nobody will see it. 
The proposed solution allows at least track such cases.

Releases branches already use cherry-pick mode so from that perspective there 
is no big changes, the only one is the origin branch from which the cherry-
pick should happen.

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia czwartek, 24 stycznia 2019 11:24:41 CET Vitaly Fanaskov pisze:
> > Why not X instead?
> > --
> > 
> > - GitFlow, GitHub <= both are based on feature branches, that doesn't work
> > well with gerrit.
> 
> So, the only problem here is gerrit (aside from personal preferences and
> habits of course). The question is shouldn't we abandon gerrit as this
> tool doesn't feet with the needs well? Inventing new approaches is of
> course super cool... But not always necessary.
> 
> What's wrong with using, say, gitflow + gitlab + upsource? Upsource is
> optional, but it's the way better for code review than gerrit.

That is a completely different discussion. If we ever want to change the 
tooling we can re-consider branching model too.

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia czwartek, 24 stycznia 2019 09:08:29 CET Liang Qi pisze:
> My concern is about "cherry-pick" a series of changes for a big
> feature, especially during the period to have "dev" branches for both
> 5 and 6. I don't have solution for this issue yet.

My assumption is that bot would cherry-pick them in the same order in which 
patches got integrated to dev. That way we could reduce amount of issues. Of 
course if the first patch from a series causes conflicts then all other would 
also be in conflict.

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 17:37:57 CET Konstantin Tokarev pisze:
> Note that backporting changes from dev should also be a full-time job for
> someone, otherwise amount of fixes going to stable branches will likely
> drop

Yes, depending who you ask it is good or bad. It means that only fixes that 
someone really cares about are really integrated to the stable branches. If 
somebody cares about a fix it means that it is more important. More over 
cherry-pick mode distributes the load of conflict resolution.

> >   - there is a chance, that some cherry-picked commits may be left
> > forgotten in gerrit after a failed integration
> 
> Or not submitted at all because of failed cherry-pick. Also, notorious
> property of cherry-pick strategy is explosion of conflicts: if there is a
> patch series modifying some code, and first of them requires adjustment to
> resolve conflict, it's likely that all fol
> lowing patches will have
> conflicts as well in the same places.

Assumption is that a bot would do the cherry-picking for you. If a cherry-pick 
cause conflicts, then the bot would push unresolved conflict to gerrit. So no, 
all changes would be in gerrit. Some may be to hard to resolve or one would 
lack a motivation. Again, main point is that it is up to author to resolve the 
conflicts.

Cheers,
  Jędrek


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

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 18:49:46 CET Thiago Macieira pisze:
> On Wednesday, 23 January 2019 08:37:57 PST Konstantin Tokarev wrote:
> > >   Disadvantages:
> > >   - git history would be a bit wilder, "git branch --contains" would not
> > >   work
> > >   - commit messages in some branches would have kind of ugly footer as
> > >   an
> > > 
> > > effect of "cherry-pick -x"
> > 
> > Gerrit's Change-Id can be used to track presence of patch in branches of
> > interest
> 
> Yes, but not as easily, since the git branch --contains and git tag
> --contains are pure DAG operations. The search you're talking about is a
> text search (usually implemented by a regexp search) on the commit message,
> with no DAG boundaries. You have to scan all valid branches for a given
> string.
> 
> And then you still have to run git branch --contains on each entry you found
> to figure out which branches contain those commits.
> 
> So this is scriptable. It's going to be something like 100x slower than
> today, but it should still finish within 10 seconds, even on slow machines.

As we would not be the only one using it, I bet the script could be 
upstream'ed to git.

Cheers,
  Jędrek


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

[Development] Proposal: New branch model

[Jedrzej Nowacki]

Hi,

  It is time to rethink our branch model. We are approaching Qt6 development 
and I'm worried that what we have now, will simply not scale. As you know, our 
branch model is mainly(*) based on merging from stable up to development 
branches. In general, it is a very good model, which make sure that release 
branches are not getting obsolete too quickly, that most of the fixes are in 
the right places, that every commit is only once in the git history. It is a 
very clean model. It is also a very slow model, with a single point of 
failure.

  It is hard to maintain:
  My impression is that the current model works great for a single release 
branch, but we have: 5.6 5.9 5.12 and soon we will have 5.13, that is without 
counting temporary patch level branches. Merging through them is hard, we 
already had to use "cherry-pick mode" in some places. When we add to the 
picture dev and qt6 branches, merging will be very, very hard. It is 
practically a full time job to update qt5 repository and coordinate all the 
merges now (thank you Liang!), shortly after qt6 branch opening amount of work 
will be much bigger.
  It is slow:
  The merges take time. We produce a lot of code, we have a lot of tests that 
needs to pass. Even single failure delays merge propagation by at least one 
day. If by bad luck, the merge contains some API incompatible changes an 
intermediate jump through Qt5 integration is required, that adds at least 3 
days of delay.

  --

  Proposal in short: let's use cherry-pick mode everywhere.

  All(**) changes would go to dev. From which they would be automatically 
cherry-picked by a bot to other branches. The decision to which branch cherry-
pick, would be taken based on a tag in the commit message. We could add a 
footer that marks the change risk level as in quip-5 
(http://quips-qt-io.herokuapp.com/quip-0005.html), so for example "dev", 
"stable", "LTS". By 
default everything would be cherry-picked to qt6 branch unless "no-future" tag 
would be given. Of course we can bike-shed about the tag names.

  Advantages:
  - no waiting for merges, a fix can be used right away after integration
  - faster propagation of fixes targeting all branches, as there are no merges 
of merges
  - simpler for new contributors, always push to dev
  - in most cases a reviewer does no need to know what the current version 
number is
  - conflict resolution is distributed and affects mostly the author of the 
change
  - documents a change intent, which may be useful for people keeping own 
forks
  - over time with increased amount of conflicts old branches, in natural way, 
stay untouched

  Disadvantages:
  - git history would be a bit wilder, "git branch --contains" would not work
  - commit messages in some branches would have kind of ugly footer as an 
effect of "cherry-pick -x"
  - there is a chance, that some cherry-picked commits may be left forgotten 
in gerrit after a failed integration

  Bot details:

  The bot would listen only for changes in dev, in some unusual cases one 
could target an other branch directly, but bot would not trigger automatic 
cherry-pick(***). The bot would wait for a successful dev integration before 
creating cherry-picked changes. The bot would use cherry-pick -x to annotate 
the origin patch. After the cherry-pick creation, it would push it to gerrit, 
+2 and stage once. It would be up to the author to re-stage in case of 
flakiness. In case of a cherry-pick conflict it should push unresolved conflict 
to gerrit and add all reviewers and author to handle the issue.

The list below shows branch targets for automatic cherry-pick based on given 
tag.

dev (qt6)
stable (qt6, 5.13)
stable, no-future (5.13)
LTS (qt6, 5.13, 5.12)
LTS-strict (qt6, 5.13, 5.12, 5.9)
LTS, no-future (5.13, 5.12)

That is assuming that we have branches: qt6  dev  5.13  5.13.q  5.12  5.12.w  
5.9  5.9.e  5.6  5.6.r
I think we should assume that patch level branches, as well LTS in very strict 
state, are handled manually.


  Creation of new branches:
We would branch more or less as usual. The only difference from the current 
system is that we would not need the back merge / soft branching anymore, but 
of course we could keep it.



  Why not X instead?
  --

  - GitFlow, GitHub <= both are based on feature branches, that doesn't work 
well with gerrit.
  - Stay with the current solution <= the merge effort is too big and qt6 is 
expected to cause conflicts that really should not be solved by one person

  What to do around Qt6 release?
  --

  Replace dev branch with qt6 branch content, do not use "no-future" tag 
anymore. From a random contributor perspective nothing changes.

  Can we use annotate instead of cherry-pick -x?
  --

  No, but we should use it in addition. 

Re: [Development] Qt6: Adding UTF-8 storage support to QString

[Jedrzej Nowacki]

Dnia środa, 16 stycznia 2019 21:12:55 CET André Pönitz pisze:
> On Tue, Jan 15, 2019 at 10:44:45PM +0100, Allan Sandfeld Jensen wrote:
> > On Dienstag, 15. Januar 2019 19:43:57 CET Cristian Adam wrote:
> > > Hi,
> > > 
> > > With every Qt release we see how the new release improved over previous
> > > releases in terms of speed, memory consumption, etc.
> > > 
> > > Any chance of having UTF-8 storage support for QString?
> > 
> > Use QByteArray when you can.
> 
> Unfortunately, quite a few APIs require to use QString, even if
> the typically use case would be completely fine even with ASCII,
> like keys in QVariantMap or QSettings.
> 
> Andre'

As a travelling person with name that can not be represented with latin1, I 
can tell you some funny stories about systems that authors thought that "ascii 
is enough". Unless you want to keep only hex codes or sha1s, please use bigger 
character set.

Cheers,
  Jędrek


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

Re: [Development] Running AVX2 code in the CI

[Jedrzej Nowacki]

On Thursday, January 10, 2019 6:32:02 PM CET Thiago Macieira wrote:
> Hello
> 
> Commit c8c5ff19de1c34a99b8315e59015d115957b3584[1] was allowed to pass the
> CI despite failing tests in a non-blacklisted test. It's fixed in [2] which
> is integrating now.
> 
> The reason this was allowed is because none of the machines in the CI are
> testing the AVX2 codepaths in qdrawhelper_avx2.cpp. So this commit is to ask
> that we add at least one machine (preferably Linux) that has that
> capability.
> 
> AVX2 along with FMA was introduced with the Haswell architecture[3] (fourth
> generation Intel Core, according to the marketing name), first launched in
> late 2013. That makes the architecture over 5 years old and it means a lot
> of our users have the feature. We ought to test it and even benchmark if we
> can.
> 
> [1] https://codereview.qt-project.org/249410
> [2] https://codereview.qt-project.org/249572
> [3] https://en.wikipedia.org/wiki/Haswell_(microarchitecture)

I have created: https://bugreports.qt.io/browse/QTQAINFRA-2541 feel free to 
amend it.

Cheers,
  Jędrek


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

Re: [Development] Use QMetaEnum::keyCount() to initialise array

[Jedrzej Nowacki]

On Monday, December 31, 2018 2:56:29 PM CET Marco Bubke wrote:
> Is it because the meta type information could be created later? What about 
adding
> a constexpr version like: QMetaEnum::compileTimeFromType? Or do we wait for
> static reflections?

Yes, sometimes, but the fact that the output changes is more problematic. This 
would break if an enum form a dynamically linked library is used, for example:

 const QMetaEnum metaEnum = QMetaEnum::fromType();
 int MyArray[metaEnum.keyCount()];

metaEnum.keyCount() value would be inlined in an app and then a Qt update, 
which adds a new enum value, would break the app. Technically you could have 
something like that:

 QVarLengthArray.keyCount>
 MyArray(metaEnum.keyCount());

but that would require new API convention and some research, because it looks 
like a nice source of bugs. Dropping BC would also help.

Cheers,
  Jędrek





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

Re: [Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

[Jedrzej Nowacki]

Dnia piątek, 2 listopada 2018 16:02:55 CET Thiago Macieira pisze:
> On Friday, 2 November 2018 06:50:50 PDT Jedrzej Nowacki wrote:
> > On Friday, November 2, 2018 4:42:52 AM CET Thiago Macieira wrote:
> > > We have a lot of API that, for Qt 6, we've already decided to extend to
> > > 64-bit on 64-bit platforms, but keep as decently-sized 32-bit on 32-bit
> > > ones.
> > 
> > Smells like qreal, with all problems that it causes... We could reconsider
> > costs of using 64bit everywhere, it would streamline debugging of edge
> > cases.
> 
> [Intel hat on]
> I don't mind this. All Intel processors are 64-bit, all Linux workloads are
> 64-bit.
> 
> [Qt maintainer hat on]
> Sorry, that would mean 32-bit builds use a larger-than-a-register type which
> means extra carry operations and slower multiplications. That's probably
> not a good idea.
I know. What I do not know is if that really matters for users, especially as 
we can use 64-bit values in API but 32-bit  values in the implementation. Nah, 
I have to admit, not the greatest idea :-) 

> > If I have to I would also pick option 4, but:
> > 1. qsizetype can _not_ be a built in metatype in Qt5 (at best an alias).
> 
> It's not going to be. It's a typedef to either int or long long, depending
> on your pointer's size.
Good

> > 2.  qsizetype needs to have QDataStream operators so it doesn't fallback
> > to
> > a  platform dependent size
> 
> Since it's a typedef, that can't happen. But you've got a point: we need to
> serialise in explicit 64-bit widths.
Yes that was the thing I tried to express :-)

> > 3. QDataStream stream autotests of class that uses the type would need to
> > be> 
> >  extended.
> > 
> > 4. I bet there is more, issues to solve, caused by pointer arithmetic ...
> 
> No doubt. That's why I wanted to start now.
> 
> > I would not try to trick qdoc to not see it. The consequences of size
> > changing  "randomly" are far too important, to be hidden.
> 
> So you want users to know now, in Qt 5, that this particular type in the API
> will become qsizetype in Qt 6?
Yes, or to turn it around, why not? It sounds like an information, which 
doesn't obscure generated documentation and which would implicitly document 
porting Qt5->Qt6. On the other hand it is a really minor detail, both 
approaches are valid :-).

Cheers, 
  Jędrek


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

Re: [Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

[Jedrzej Nowacki]

On Friday, November 2, 2018 4:42:52 AM CET Thiago Macieira wrote:
> We have a lot of API that, for Qt 6, we've already decided to extend to
> 64-bit on 64-bit platforms, but keep as decently-sized 32-bit on 32-bit
> ones.

Smells like qreal, with all problems that it causes... We could reconsider 
costs of using 64bit everywhere, it would streamline debugging of edge cases.

>  (...)
> Option 4: create a central #if and use this new type, starting now
> Same as #3, but instead of per class, it would be central. Moreover, with
> one preprocessor trick (-Dnewinttype=int), we can fool qdoc into generating
> documentation as it is today. In Qt 6, once we decide we don't need Qt 5
> merging anymore, we can also do a global search-and-replace to qsizetype
> (optional).

If I have to I would also pick option 4, but:
1. qsizetype can _not_ be a built in metatype in Qt5 (at best an alias).
2.  qsizetype needs to have QDataStream operators so it doesn't fallback to a 
platform dependent size
3. QDataStream stream autotests of class that uses the type would need to be 
extended.
4. I bet there is more, issues to solve, caused by pointer arithmetic ...

I would not try to trick qdoc to not see it. The consequences of size changing 
"randomly" are far too important, to be hidden.

Cheers,
  Jędrek


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

Re: [Development] Metatype system in Qt6

[Jedrzej Nowacki]

Dnia poniedziałek, 29 października 2018 18:46:18 CET Olivier Goffart pisze:
> On 10/29/18 5:39 PM, Jedrzej Nowacki wrote:
> > Hi everyone!
> > 
> >While main heat on the mailing list is taken by topic how to encode
> >that we
> > 
> > are nice, friendly and respectful to each other, I would like to show some
> > side project that I had. It is a proposal for base of metatype system for
> > Qt6. You can look and comment at it here:
> > https://github.com/nierob/qmetatype. It is quite fresh and it was rather
> > a storage for functionality ideas. I haven't tried to compare performance
> > of it to the current system, but for sure it has more flexibility and I
> > believe, that conceptually it could serve us during Qt6. Anyway before
> > spending too much time on it I would like to get some early feedback and
> > questions.
> 
> The discussion in that other thread are not finished, so please wait until
> there is consensus before being nice!
Well I prefer publish it now and work in the open. I do not expect everyone 
jumping to the topic , dropping everything else, but at least some people can 
look at the code :-) There is no rush, for me it is an achieved milestone. Now 
the harder work slowly may happen.

> But thanks for caring about the QMetaType system.
Thanks for looking at the code!

> I had a short look. I think it would be usefull if you already used names
> closer to what they are supposed to be. Namespace N, P, are not so nice
> names.
N is next, P is private, kind of my personal standard. 

Action point for me:
 - updated P to QtPrivate
 - see how many name clashes I will get after removing N.

> The idea of using a single function with operation is quite a good idea I
> like it. As long as the function takes the typeid as a parameter.
> Indeed, I'm thinking about dynamic types that would come from language
> bindings: in this situation, while it is easy to allocate memory on the
> heap, it is not easy to create a new function pointer for every dynamic
> type that we would register.
Let's postpone that discussion to a moment that we agree on the extensions.

> Regarding the extension, i don't know if it is such a good idea, because you
> never know what you can rely on.
> say you have a QVariant with some type that comes from some part of your
> code, how do you know if you can print it with qDebug, or convert it to
> string, how do you register that?
> IMHO, there should not be extensions! All operation that we want to make
> available for a type should be always available. Using SFINAE to find out if
> it is available.
Extensions in that respect do not change anything, because it is about error 
handling. How to inform a user that a type is not qdebug stream-able or can 
not be converted to QString. In the current and the data driven approach you 
would need to check if the right function pointer is null or not and on top of 
this the error handling still would need to happen as the call itself could 
fail. With the proposed solution you have only one point in which you handle 
potential errors, just after the metatype call.

So let's return to QVariant concern that you expressed. I believe that if you 
plan to use a feature you need to ensure that you can. So I would propose 
QVariant constructor to look more or less like qVariantFromValue, it would do 
the "registration" it needs. It is in sync with QObject registering own 
properties types.

SFINAE would be used in extensions, as I showed in https://github.com/nierob/
qmetatype/blob/master/extensions/streams.h, still error handling is missing 
there. Actually I think it is wrong layer for detection, creating dummy 
handlers is wrong.

Action points for me:
- show in a better way that extensions can be added lazily
- improve error handling in metatype call
- highlight more common set of operations that would be used if qTypeId() 
is called
- move stream SFINAE detection a bit higher in the code stack
 
> So what are the operation we want on a QMetaType:
> 
> - for QVariant, and the queued connections: copy / destruction.  Ideally in
> place. So we also need the size/alignement to be able to allocate the memory
> 
> - for qDebug, we need the QDebug operator <<
> 
> - for QDataStream, we need the operator << and >>, and an unique identifier
> that stay the same. Currently, this is the type id for builtin types, and
> the name for custom type. I suggest we use the name, if we want to keep
> compatibility with old steam, we will need to keep a mapping from old type
> id, to new name.
I'm pretty sure that you are aware that the list is far from being complete, 
so I will not neat pick on this, but how you make sure that every future use 
case would satisfied? Hiding functionality behind a function and extensible 
data stru

[Development] Metatype system in Qt6

[Jedrzej Nowacki]

Hi everyone!

  While main heat on the mailing list is taken by topic how to encode that we 
are nice, friendly and respectful to each other, I would like to show some 
side project that I had. It is a proposal for base of metatype system for Qt6. 
You can look and comment at it here: https://github.com/nierob/qmetatype. It 
is quite fresh and it was rather a storage for functionality ideas. I haven't 
tried to compare performance of it to the current system, but for sure it has 
more flexibility and I believe, that conceptually it could serve us during 
Qt6. Anyway before spending too much time on it I would like to get some early 
feedback and questions.

Cheers,
  Jędrek


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

Re: [Development] Closing issues automatically with new keyword

[Jedrzej Nowacki]

On Friday, September 21, 2018 1:02:10 PM CEST Tor Arne Vestbø wrote:
> > On 21 Sep 2018, at 12:47, Jedrzej Nowacki  wrote:
> > 
> > On Friday, September 21, 2018 9:07:14 AM CEST Sami Nurmenniemi wrote:
> > 
> >> I committed this to 5.11 branch:
> >> https://codereview.qt-project.org/#/c/240566/
> >> 
> >> Now Gerrit Bot marked this as fixed in 5.11.0, which is not correct:
> >> https://bugreports.qt.io/browse/QTBUG-70493
> >> 
> >> I'm not sure if it should automatically select the next unreleased
> >> version
> >> (5.11.3) or use more general version (5.11) or if I used it incorrectly.
> >> 
> >>> On Tuesday, September 4, 2018 10:24:17 AM CEST Frederik Gladhorn wrote:
> >>> 
> >>>> One thing that would still be great to have is the jira links working
> >>>> so
> >>>> that the changes show up in JIRA like they do for Task-number, I'm
> >>>> looking
> >>>> into this and thought the config was fixed, but so far that doesn't
> >>>> seem
> >>>> to
> >>>> do the trick...
> >>> 
> >>> 
> >>> Looks like I nudged it in the right way nwo (writing the config
> >>> slightly
> >>> differently, why one version works and the other doesn't is beyond me).
> >>> You should now get jira to show gerrit links when using Fixes.
> > 
> > 
> > I looked into the code... That happened because none of these commands 
> > returned 5.11.x:
> > git show-ref --tags
> > git show-ref —heads
> 
> 
> Shouldn’t that pick refs/heads/5.11?
> 
> Tor Arne

Yes, that is what happened. The first release branch for 5.11 is 5.11.0, 
therefore it marked 5.11.0 as fixed version.

Jędrek



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

Re: [Development] Closing issues automatically with new keyword

[Jedrzej Nowacki]

On Friday, September 21, 2018 9:07:14 AM CEST Sami Nurmenniemi wrote:
> I committed this to 5.11 branch:
> https://codereview.qt-project.org/#/c/240566/
> 
> Now Gerrit Bot marked this as fixed in 5.11.0, which is not correct:
> https://bugreports.qt.io/browse/QTBUG-70493
> 
> I'm not sure if it should automatically select the next unreleased version
> (5.11.3) or use more general version (5.11) or if I used it incorrectly.
> > On Tuesday, September 4, 2018 10:24:17 AM CEST Frederik Gladhorn wrote:
> > > One thing that would still be great to have is the jira links working so
> > > that the changes show up in JIRA like they do for Task-number, I'm
> > > looking
> > > into this and thought the config was fixed, but so far that doesn't seem
> > > to
> > > do the trick...
> > 
> > Looks like I nudged it in the right way nwo (writing the config slightly
> > differently, why one version works and the other doesn't is beyond me).
> > You should now get jira to show gerrit links when using Fixes.

I looked into the code... That happened because none of these commands 
returned 5.11.x:
 git show-ref --tags
 git show-ref --heads
So from the bot perspective 5.11 branch was never released therefore 5.11.0 is 
the next release. For me it looks quite sane, who can add missing tags?

Cheers,
  Jędrek



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

Re: [Development] Qt 6 buildsystem support requirements

[Jedrzej Nowacki]

On Tuesday, July 31, 2018 8:15:50 PM CEST Ville Voutilainen wrote:
> On 31 July 2018 at 20:49, Thiago Macieira  wrote:
> > I know CMake meets these requirements, but it has other problems and the
> > fact that it currently does not build Qt. On that front, qbs is ahead.
> > But qbs has a shorter track record. Since we're not switching
> > buildsystems in the next 2 years, there's time for the proponents of qbs
> > to take actions to achieve those requirements above.
> > 
> > In other words: get others to adopt the buildsystem before we switch Qt.
> > Prove that it can support Qt.
> > 
> > I know switching Qt would gain it a big critical mass, the same way that
> > KDE switching to CMake in 2006 gave CMake an important boost [*]. But
> > we're not switching Qt just yet, so if you're saying the tool is ready,
> > get others to use it now.
> 
> This provoked a thought in me, a way to make qbs worth all its effort:
> make debugging
> a build so staggeringly ridiculously good that it becomes attractive
> to use it. I don't know
> what debugging builds done with python-based build systems is like,
> but debugging make-based
> builds is rather horrible.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Oh debugging... 



I would love a build system that actually thinks about real world in which 
sub-processes are crashing, getting locked or became unusually slow. One that 
automatically attach debugger and scans operating system for basic issues, for 
example I would like to see something like that:

"error: ABC process crashed, here there is backtrace of it (...) at the time 
of the crash memory usage was ~ZZ% and avg load of Y, in parallel we were 
executing processes: BGD, SFD"
"warning: CBA process seems to not doing anything for last X minutes, the avg 
load is 1% for the last 30s, maybe try strace with PID to debug it?"
"warning: performance may be poor because of a heavy swap usage"
"error:  you are almost out of disk space (~300 MB) suspending the build"
"warning: process HBG runs already for X minutes, constantly using whole CPU"

A system that is aware of memory constrains and CPU limits. So I'm not 
surprised if like with make suddenly -j60 doesn't work as expected because I 
have changed to a network without icecream scheduler. A system that 
automatically limits number of parallel tasks if swap is getting full to avoid 
out of memory kills.



Cheers,
  Jędrek


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

Re: [Development] QTBUG-43096 - QML instantiation performance decadence

[Jedrzej Nowacki]

On Saturday, May 26, 2018 2:05:38 PM CEST Simon Hausmann wrote:
> Jędrzej had a beautiful proof of concept at some point for QObject to
> combine the object and d-pointer allocation into one.

Old times :-) 
For completeness: https://codereview.qt-project.org/#/q/status:deferred
+project:qt/qtbase+branch:dev+topic:qobject_operator_new,n,z



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

Re: [Development] Dropping of MSVC 2013

[Jedrzej Nowacki]

Hi,

  We really should think about some more or less automatic policy about 
supported platforms. Discussing that on each release is not great nor for us, 
nor for our users. It takes time, to discuss it.  I guess that from outside it 
is  looking as a complete chaos, especially in context of LTS, some would 
expect that after LTS we drop support for old compilers/platforms, some would 
expect a deprecation warning first :-)

Cheers,
  Jędrek


From: Development  on 
behalf of Alex Blasche 
Sent: Wednesday, November 8, 2017 7:57:32 PM
To: Shawn Rutledge; Jani Heikkinen
Cc: Thiago Macieira; development@qt-project.org
Subject: Re: [Development] Dropping of MSVC 2013

>From: Shawn Rutledge 

>> On 18 Oct 2017, at 07:34, Jani Heikkinen  wrote:
>> We discussed about this last spring and then the decision was that 5.10 is 
>> too early but 5.11 might be possible.
> So can we get that done soon on dev branch?

Sorry, no. As mentioned during the contributor summit, this decision is tabled 
until we have the 5.10 download figures.

--
Alex
___
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] Continuous Integration issues - Coin temporarily down

[Jedrzej Nowacki]

On Thursday, November 2, 2017 11:28:22 AM CET Jedrzej Nowacki wrote:
> Well, almost, 5.9 is blocked because of a bug in provisioning script
> (https:// codereview.qt-project.org/#/c/209874/). Let's hope that is the
> end of the series of failures that we had for the last days.
> 
> Cheers,
>   Jędrek

Gerrit joined the party, some patches are in a wrong state. If you see 
something that is hanging in integrating or stating state, or if a patch set 
is merged, but it is not marked as such in gerrit, then please contact out 
gerrit admins. 

There is also a good news, https://codereview.qt-project.org/#/c/209874/ was 
merged so 5.9 should work now.

Thanks,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Continuous Integration issues - Coin temporarily down

[Jedrzej Nowacki]

On Thursday, November 2, 2017 9:32:10 AM CET Jedrzej Nowacki wrote:
> Everything should be functional today. Have fun.
> 
> Cheers,
>   Jędrek

Well, almost, 5.9 is blocked because of a bug in provisioning script (https://
codereview.qt-project.org/#/c/209874/). Let's hope that is the end of the 
series of failures that we had for the last days.

Cheers,
  Jędrek


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

Re: [Development] Continuous Integration issues - Coin temporarily down

[Jedrzej Nowacki]

On Wednesday, November 1, 2017 2:59:22 PM CET Jedrzej Nowacki wrote:
> Hi,
> 
>   Yet another update. We narrowed down the IO issue. The network update from
> 1G to 10G, mentioned before, brought compellent into the picture and that
> one didn't want to cooperate nicely with our btrfs installation, for an
> unknown reason.  The link will be downgraded and we would go back to a SSD
> storage as soon as possible (currently there are some disk operations that
> can not be interrupted).
> 
>   Regarding 5.10 branch, it is still locked, but I guess it is not a
> surprise. https://codereview.qt-project.org/#/c/209970/ needs to be get
> integrated, but in the current hostile conditions it is not easy.
> 
> Cheers,
>Jędrek

Everything should be functional today. Have fun.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Continuous Integration issues - Coin temporarily down

[Jedrzej Nowacki]

Hi,

  Yet another update. We narrowed down the IO issue. The network update from 1G 
to 10G, mentioned before, brought compellent into the picture and that one 
didn't want to cooperate nicely with our btrfs installation, for an unknown 
reason.  The link will be downgraded and we would go back to a SSD storage as 
soon as possible (currently there are some disk operations that can not be 
interrupted). 

  Regarding 5.10 branch, it is still locked, but I guess it is not a surprise. 
https://codereview.qt-project.org/#/c/209970/ needs to be get integrated, but 
in the current hostile conditions it is not easy.

Cheers,
   Jędrek

From: Development <development-bounces+jedrzej.nowacki=qt...@qt-project.org> on 
behalf of Jedrzej Nowacki <jedrzej.nowa...@qt.io>
Sent: Wednesday, November 1, 2017 11:19 AM
To: development@qt-project.org
Subject: Re: [Development] Continuous Integration issues - Coin temporarily down

On Wednesday, November 1, 2017 10:16:53 AM CET Jedrzej Nowacki wrote:
> On Wednesday, November 1, 2017 8:50:06 AM CET Jedrzej Nowacki wrote:
> > On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote:
> > > Hi all,
> > >
> > > we've had a bunch of unfortunate small things piling up, so sadly Coin
> > > is
> > > down right now. I expect it to be up tomorrow (so in roughly 10 hours
> > > from
> > > now) assuming everything now goes smooth.
> >
> > Small update. Now everything is going back to a working state. Durring the
> > process we droppped provisioned images and these are being re-created now.
> > Self healing process can take 1-3h, everything is populated in parallel
> > and
> > heavily depends on network, so the ETA is hard to estimate.
> >
> > NOTE:
> > Some integrations may break in provisioning step, in that case feel free
> > to
> > restage.
>
> RHEL 7.2 fails to provision as we have a subscription issue. That
> effectively blocks 5.10 branch in all modules. We will probably just update
> the RHEL to 7.4 as it is needed anyway. More details can give Liang and
> Heikki.

And now we are experiencing unexpected, extremely slow IO on the OpenNebula
host. Our IT is working on it, but I'm afraid that nothing will pass until it
is fixed, we run at ~5% of standard computation power.

Cheers,
  Jędrek
___
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] Continuous Integration issues - Coin temporarily down

[Jedrzej Nowacki]

On Wednesday, November 1, 2017 10:16:53 AM CET Jedrzej Nowacki wrote:
> On Wednesday, November 1, 2017 8:50:06 AM CET Jedrzej Nowacki wrote:
> > On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote:
> > > Hi all,
> > > 
> > > we've had a bunch of unfortunate small things piling up, so sadly Coin
> > > is
> > > down right now. I expect it to be up tomorrow (so in roughly 10 hours
> > > from
> > > now) assuming everything now goes smooth.
> > 
> > Small update. Now everything is going back to a working state. Durring the
> > process we droppped provisioned images and these are being re-created now.
> > Self healing process can take 1-3h, everything is populated in parallel
> > and
> > heavily depends on network, so the ETA is hard to estimate.
> > 
> > NOTE:
> > Some integrations may break in provisioning step, in that case feel free
> > to
> > restage.
> 
> RHEL 7.2 fails to provision as we have a subscription issue. That
> effectively blocks 5.10 branch in all modules. We will probably just update
> the RHEL to 7.4 as it is needed anyway. More details can give Liang and
> Heikki.

And now we are experiencing unexpected, extremely slow IO on the OpenNebula 
host. Our IT is working on it, but I'm afraid that nothing will pass until it 
is fixed, we run at ~5% of standard computation power. 

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Continuous Integration issues - Coin temporarily down

[Jedrzej Nowacki]

On Wednesday, November 1, 2017 8:50:06 AM CET Jedrzej Nowacki wrote:
> On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote:
> > Hi all,
> > 
> > we've had a bunch of unfortunate small things piling up, so sadly Coin is
> > down right now. I expect it to be up tomorrow (so in roughly 10 hours from
> > now) assuming everything now goes smooth.
> 
> Small update. Now everything is going back to a working state. Durring the
> process we droppped provisioned images and these are being re-created now.
> Self healing process can take 1-3h, everything is populated in parallel and
> heavily depends on network, so the ETA is hard to estimate.
> 
> NOTE:
> Some integrations may break in provisioning step, in that case feel free to
> restage.

RHEL 7.2 fails to provision as we have a subscription issue. That effectively 
blocks 5.10 branch in all modules. We will probably just update the RHEL to 
7.4 as it is needed anyway. More details can give Liang and Heikki.

Ossi, Frederik: could you disable staging button for 5.10 branch?

Cheers,
   Jędrek


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

Re: [Development] Continuous Integration issues - Coin temporarily down

[Jedrzej Nowacki]

On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote:
> Hi all,
> 
> we've had a bunch of unfortunate small things piling up, so sadly Coin is
> down right now. I expect it to be up tomorrow (so in roughly 10 hours from
> now) assuming everything now goes smooth.
> 

Small update. Now everything is going back to a working state. Durring the 
process we droppped provisioned images and these are being re-created now. 
Self healing process can take 1-3h, everything is populated in parallel and 
heavily depends on network, so the ETA is hard to estimate. 

NOTE:
Some integrations may break in provisioning step, in that case feel free to 
restage.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt with sanitizers

[Jedrzej Nowacki]

Hi,

  I made an experiment to see if we should enable sanitizers in CI, by 
default. Essentially, how much we would slow down integrations and what would 
be the tests pass rate. Short answer is that, currently, it is not an option, 
but I produced some data, if someone is interested, please keep reading

Platform:
Linux Ubuntu_16_04 (gcc-x86_64) DeveloperBuild, OutOfSourceBuild, QtLibInfix, 
QtNamespace, BuildExamples, Documentation
GCC 5.4 (yes, it is quite old)
CPU count = 4

 Build

qt/qtbase a6546a56fa978bc9ed63203b4ef547adcfd59408 (3/5 completed)

State   Features  Duration
--- - -
DoneNormal build  28min1s
DoneConfigureWithAddressSanitizer 35min47s
DoneConfigureWithThreadSanitizer  42min44s
Error   ConfigureWithMemorySanitizer  0min55s
Error   ConfigureWithUndefinedSanitizer   4min35s


 Test

qt/qtbase a6546a56fa978bc9ed63203b4ef547adcfd59408 (1/5 completed)

State   FeaturesDuration
--- --- -
DoneNormal build51min59s
Error   ConfigureWithAddressSanitizer   1h9min57s
Error   ConfigureWithThreadSanitizer1h49min8s
Cancelled   ConfigureWithMemorySanitizer
Cancelled   ConfigureWithUndefinedSanitizer


At first, I could not even build qtbase, only after applying this https://
codereview.qt-project.org/#/c/208359/ I managed to fix linking issues. Sadly 
ConfigureWithMemorySanitizer and ConfigureWithUndefinedSanitizer failed to 
build 
and I had no immediate idea how to fix them so I ignored the problem.

The logs from the tests execution are big. Quite a lot of issues were found 
and some were definitely valid. If you look into them, remember that some tests 
failed, therefore they could potentially produce an odd outcome.

Interesting part of logs are here:
Filename: logs.tar.gz
Filesize: 4.29 MB
Download link: 
https://filesender.qt.io/?vid=3775e69f-3d64-f5a9-a225-3c357692
The file is available until 07-11-2017 after which it will be automatically 
deleted.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS 2017 QtCore sessions

[Jedrzej Nowacki]

On wtorek, 17 października 2017 17:28:54 CEST Marc Mutz wrote:
> > (...)
> > Discussion not finished
> 
> I certainly hope so, because the above does not make any sense. See my
> talk at QtWS. Returning QStringView is not different from c.begin() or
> str.data(). You need to document the lifetime of the data, that's it.
> (...)

As a person reading docs only if something is not working as expected, I'm 
pondering, if there is a way to document the lifetime without documentation. 
It seems that QStringView shares problems of raw pointers and raw pointers 
issue was mostly solved by different smart pointers. So why not returning one 
of these:

QViewValidAsLongAsObjectFoo 
QViewValidUntilTheNextCall
QViewValidAsLongMoonIsTheRightPhase

Some of these could be enforced by asserts, some could be just for documenting 
the issue. Anyway, just an idea :-)

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)

[Jedrzej Nowacki]

If you do like that then you are doing it wrong. Review process is _not_ based 
on a name / company / sun activity. It is  based on the change content. Even 
best people do mistakes.

Cheers,
  Jędrek

On piątek, 13 października 2017 15:48:51 CEST Viktor Engelmann wrote:
> I am thinking about the scenario when I read a 300 line commit and I am
> unsure about some of the lines. Say it removes one include and adds
> another include.
> 
> If that commit comes from someone whom I talk to every day - someone
> whom I know to be very concerned about security and privacy - and
> someone I know is competent and has approver rights - I might ignore
> these 2 lines and assume that the compiler will fail on the CI in case
> the removed header was still needed.
> 
> When the commit comes from someone whom I have never heard of - I will
> look into whether there is a symbol that will now be resolved
> differently - and if there is, I assume that this "differently" opens a
> backdoor.
> 
> On 13.10.2017 14:52, Marc Mutz wrote:
> > On 2017-10-13 13:04, Viktor Engelmann wrote:
> >>  * I don't think we need to be as paranoid towards contributions
> >> from
> >> our own employees as we need to be towards external contributions.
> > 
> > I believe you got that the wrong way around :)
> > 
> > Thanks,
> > Marc


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

Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)

[Jedrzej Nowacki]

Please, do not jump immediately to a conclusion. It was Viktor's proposal 
which does not represent "TQC administration" whatever it is. Qt-project has 
own rules and it is self-governmented. Just to be fair, you could also notice 
my answer to the proposal:
> I do not agree. An employer name does not matter.
and I do work for The Qt Company.

Cheers,
  Jędrek

On piątek, 13 października 2017 14:51:13 CEST Alexander Nassian wrote:
> That shows exactly the mindset of the TQC administration. Let the community
> do the work and squeeze all customers and force them to use commercial
> licensing by using fear...
> 
> 
> Beste Grüße / Best regards,
> Alexander Nassian
> 
> > Am 13.10.2017 um 14:46 schrieb André Somers :
> > 
> > Op 13/10/2017 om 13:04 schreef Viktor Engelmann:
> >> 4. I don't think we need to be as paranoid towards contributions from our
> >> own employees as we need to be towards external contributions.> 
> > So much for open government...
> > 
> > André
> > 
> > ___
> > 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] Speeding up the review process (was: PostgreSQL cross compile for Pi)

[Jedrzej Nowacki]

On piątek, 13 października 2017 13:04:46 CEST Viktor Engelmann wrote:
> On the [Interest] mailing list there was a discussion about the
> review-process taking to long and we also had multiple discussions about
> that at the world summit. I have complained about this myself, so I
> would like to start a new thread and collect your thoughts and ideas on
> how to improve the situation.
> 
> My suggestions would be
> 
>  1. Allow approving your own commits under certain circumstances. examples:
>  1. when you only changed minor things like a variable name (except
> in public API), a string, a comment or qdoc entry
>  2. when you already had a +2 and only changed minor things like a
> variable name, a string, a comment or qdoc entry (or more
> generally: when you already had a +2 and only did something that
> is also on this list :-D )
>  3. when you only increased a timeout in an autotest. Increasing
> timeouts is a safe change - it can only solve false negatives
> and false positives, but not create false positives or false
> negatives.
>  4. or more general: when you only made an autotest harder to pass -
> like adding a Q_VERIFY, Q_COMPARE, etc.
>  5. when the change is something auto-generated - like you just
> updated plugins.qmltypes using qmlplugindump
>  6. when you only changed something in accordance to the guidelines
> - like Q_DECL_OVERRIDE -> override
>  7. when you have a certain count of +1's from people who have
> approver rights
That doesn't solve the problem, no brainers are getting review quite quickly. 
Some more detailed comments below:
 - In 2, you would need to amend the commit message too.
 - 3 is  at best controversial, do not increase timeouts, rewrite the test 
instead.
 - I'm not convinced with 4, it may happen that one is enforcing wrong or 
invalid behaviour.
 - I'm afraid that as a result of 7 people will not give +1s anymore :-)
Review as a process is good, it may be annoying but it is proven to increase 
quality of the code.

>  2. Towards that last point: I think many of us are afraid to get blamed
> for +2'ing something that causes problems later (introduces a new
> bug or so), but as far as I have seen, nobody gets blamed for such
> problems, so we should not be THAT afraid of approving something.
> Also, don't forget that there is still the CI to get past!
I like how you believe in CI, I share it, but check our test coverage, we are 
far from perfect.

>  3. Remember that brain-cycles are far more expensive than CPU cycles -
> so when in doubt, rather test-run something on the CI than make a
> human think about whether the CI "would" accept it. If that causes
> CI outages, we need to buy more CI machines. It is just a naive
> fallacy to "save" CI expenses by assigning the CI's work to
> employees who are much more expensive.
The sentence suggests that we have code review process to cut CI expenses, 
that is simply not true. Anyway, it is not that easy as you wrote there are 
limits of scalability. 

>  4. I don't think we need to be as paranoid towards contributions from
> our own employees as we need to be towards external contributions.
I do not agree. An employer name does not matter.

>  5. Set a deadline for criticism on the general approach to a change.
> Too often I have had the situation that I uploaded a patch, then we
> debated the qdoc entries, variable names, method names, etc FOR
> MONTHS - and when I thought we were finally wrapping up and I could
> soon submit it, someone else chimes in and says "this should be done
> completely differently". Even if the person is right - they should
> have said that months earlier - before I wasted all that valuable
> time on variable names, compliance with qdoc guidelines, etc.
> In earlier discussions I have been told that such a deadline would
> have to be long, because someone who might have an opinion might be
> on vacation. IMHO, this doesn't count, because a) you can still make
> an exception to the rule in such a situation and b) by that logic
> you should never approve anything, because we also might hire a new
> employee in 10 years who might have an opinion.
I agree that such situation should not happen, it really should be avoided. I 
have experienced that few times and I know how annoying and demotivating it 
is. In the same time it can not be an excuse to commit a broken code.


I do agree that it takes to long to pass code review, but I do not think that 
giving up on review is a good idea.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding Qt CoAP

[Jedrzej Nowacki]

On Monday, September 4, 2017 11:58:13 AM CEST Thiago Macieira wrote:
> > True, but we can re-evaluate if it is not working, modularization is
> > harder
> > in general as it requires some code changes. Regarding the "two weeks"
> > delay, it is mostly a social problem, as we can not agree on how often qt5
> > submodule update should happen, the status quo is kept and it happens
> > randomly and on a request.
> 
> It's usually one week for someone to go and start the merge. And then one
> more  week to get that past the CI.

There is a difference between merge and submodule update. If you do not work 
against different branches, a submodule update is enough and that one may be 
quite cheap. Again, it is a social issue, technically there is no problem in 
updating just one module in Qt5. Depending on the module, cost of it is; zero 
(leaf modules) to full Qt5 buid and test (qtbase), but currently we prefer to 
update all of them and that triggers full rebuild and test (currently we are 
reaching the target of 4.5h per qt5 integration, so assuming no failures it is 
not that bad).

In addition you do not need to wait for someone to create a submodule update, 
it is quite easy operation. Just make a commit with a new sha1.


We should do merges and submodule updates automatically, as often as possible 
(yes, even few times per day). Yes, it will pollute git log with "Update" and 
"Merge" commits, but I can not force myself to care about it (btw. it may be 
solvable for qt5 repo, but it would require a shadow copy and a direct push).


Cheers,
  Jędrek


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

Re: [Development] Adding Qt CoAP

[jedrzej . nowacki]

On Monday, September 4, 2017 9:14:37 AM CEST Thiago Macieira wrote:
> On Saturday, 2 September 2017 16:54:03 -03 Jędrzej Nowacki wrote:
> > On piątek, 1 września 2017 08:38:19 CEST Thiago Macieira wrote:
> > > I'm also wondering if we shouldn't have a bigger repo for IoT-related
> > > things,  instead of creating a small one for each thing.
> > 
> > Currently, from CI and releasing perspective heaving dozen of small repos
> > is easier and faster. All these modules are quite distinct, so joining
> > them would not give any adventage to our users nor us apart of a good
> > feeling of grouping things together.
> 
> Except if one depends on the other. In which case we can't start adding 
> features until qt5 integrates and that usually takes about two weeks happen.
> 
> Anyway, there aren't any dependencies expected so far (aside from DTLS,
> which  should be in QtNetwork).

True, but we can re-evaluate if it is not working, modularization is harder in 
general as it requires some code changes. Regarding the "two weeks" delay, it 
is mostly a social problem, as we can not agree on how often qt5 submodule 
update should happen, the status quo is kept and it happens randomly and on a 
request.

  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Removal of some of the blacklisted (non-working) autotests?

[Jedrzej Nowacki]

> Now: what should it do ?
Compile the test with additional debugging flags.

On Linux it would be looking like that:

for 10 min (minimum 3000 runs):
Run the test
Run the test with valgrind
Use taskset to reduce CPU affinity to one CPU
Put external load on the CPU to re-arrange threads schedule
Use  other tools?

If it failed even once the change should be rejected. I'm not sure what should 
we do with warnings I guess we can not thread them as errors, but definitely we 
can print them out.

Cheers,
  Jędrek



From: Edward Welbourne
Sent: Wednesday, November 9, 2016 11:05:24 AM
To: Jedrzej Nowacki
Cc: development@qt-project.org
Subject: Re: [Development] Removal of some of the blacklisted (non-working) 
autotests?

Jedrzej Nowacki said:
> As you wrote, in the first iteration of the functionality I would go
> for an easy solution and I would detect just all modifications to
> tests/auto/*
> On the other hand I do not want to have the definition of stress
> testing in Coin code. Every one should be able to run it

Fair enough.

> therefore it should be a make target.  So everyone could just type:
>   make stress-test
> in a test folder and after 10 min get the result.

Makes sense - nice target, well worth adding to Makefiles.
Now: what should it do ?

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

Re: [Development] Removal of some of the blacklisted (non-working) autotests?

[Jedrzej Nowacki]

As you wrote, in the first iteration of the functionality I would go for an 
easy solution and I would detect just all modifications to tests/auto/* On the 
other hand I do not want to have the definition of stress testing in Coin code. 
Every one should be able to run it therefore it should be a make target.  So 
everyone could just type:
  make stress-test
in a test folder and after 10 min get the result.

Cheers,
  Jędrek

From: Edward Welbourne
Sent: Friday, November 4, 2016 9:36 AM
To: Jedrzej Nowacki
Cc: development@qt-project.org
Subject: Re: [Development] Removal of some of the blacklisted (non-working) 
autotests?

Jędrzej Nowacki contributed:
> Even more, we need something that would not allow flaky, badly written
> test to be merged to Qt in the first place, otherwise we would have
> that discussion again in next 12 months.

How practical would it be to coax CI/Gerrit into recognising when a
commit adds new tests, so as to include stress-testing of the new test
as part of the CI testing ?  A half-way-decent start would be to notice
any tests/auto/* files modified by the commit and have the testing make
check in the affected directories several times, instead of just once.
For bonus marks, when the test branch has several commits in it, only
fail the commits that do touch those test files, if those tests show a
mix of passes and fails.

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

Re: [Development] Coin update

[Jedrzej Nowacki]

Hi,

   The update went terribly wrong. We essentially lost the machine, because of 
a snapshot which corrupted partition. We needed to reinstall everything. The 
machinery is running now, but it doesn't accept standard builds until we 
reconstruct cache (qt5 builds for all active branches). It can take 2-3 hours.

  Sorry for the inconvenience.

Cheers,
  Jędrek

From: Development <development-bounces+jedrzej.nowacki=qt...@qt-project.org> on 
behalf of Jedrzej Nowacki <jedrzej.nowa...@qt.io>
Sent: Tuesday, October 25, 2016 9:26:02 AM
To: development@qt-project.org
Subject: [Development] Coin update

Hi,
  We need to update the Coin server, so the service will be interrupted for a 
while today. Sorry for the short notice.
Cheers,
  Jędrek
___
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] Coin update

[Jedrzej Nowacki]

Hi,
  We need to update the Coin server, so the service will be interrupted for a 
while today. Sorry for the short notice.
Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Coin news

[Jedrzej Nowacki]

Good news everyone!

Changing Coin to test changes against Qt5 instead of the latest version of all 
modules reduced load on the CI significantly and now the build queue is sane 
even in rush hours (reaching around ~250 items instead of ~1700). I hope every 
one feels that integrations are quicker, especially on leaf modules.

As we managed to reduce the load, we are now hitting a new bottle neck in CI. 
Qt5 updates are not passing often enough and they are crucial, not only for 
releases, but for the whole system. As the first step, we will reduce quality 
criteria for "flaky" definition for Qt5 integrations. Currently, if Coin 
encounters a test failure it tries to re-run it 5 times in addition. If all 
pass then the test run is accepted. For Qt5 we will re-run the test only once. 
The change is based on assumption that flakiness, in most cases, is not caused 
by an intermodule operation and we believe that the assumption is correct. 

I would like to also remind everyone, that intermodule API changes need to be 
merged in two steps. For example if you plan to change a method "void foo()" in 
qtbase to "void foo(const QString&)", that would be the right order of 
execution:
1. Commit a change to qtbase that _adds_  foo(const QString&)
2. Update all modules that use foo() to use foo(const QString&)
3. Wait until Qt5(dev branch) submodule update, that gathers changes from 1 and 
2
4. Remove old foo() from qtbase
If you do not follow we would have to revert your changes.

Cheers,
  Jędrek

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

Re: [Development] macOS CI node segfault

[Jedrzej Nowacki]

Yes, it is possible, but that would be a manual work. From that perspective I 
would prefer to focus on automatic uploading core dumps. Fredrik volunteered to 
look into that (thanks!)

Cheers,
  Jędrek


From: Development  on 
behalf of Sérgio Martins 
Sent: Monday, October 10, 2016 4:25 PM
To: Thiago Macieira
Cc: development@qt-project.org
Subject: Re: [Development] macOS CI node segfault

On Sat, Oct 8, 2016 at 9:52 PM, Thiago Macieira
 wrote:
> That said, we've known moc has been crashing on Mac for a couple of months and
> we have no idea what's causing it.

I recently hit a moc crash when compiling KHTML, then replaced moc
with a script that called "valgrind moc $@", gave the report to
olivier and he fixed it immediately.
Is it possible to trigger a manual build on macOS node and try until
it crashes ?


Regards,
Sérgio Martins
___
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] macOS CI node segfault

[Jedrzej Nowacki]

Bug report for it doesn't exist it is something hanging in back of our heads 
for months, but feel free to fill the form.

Cheers,
  Jędrek


From: Sean Harmer <s...@theharmers.co.uk>
Sent: Monday, October 10, 2016 9:11 PM
To: Jedrzej Nowacki; development@qt-project.org
Subject: Re: [Development] macOS CI node segfault

On 10/10/2016 09:14, Jedrzej Nowacki wrote:
> As Thiago said. Moc is crashing on OSX for an unknown reason. It is
> unlikely to be RAM problem,  because we would see much wider
> distribution of crashes (related bug report:
> https://bugreports.qt.io/browse/QTQAINFRA-990).

Argh, sorry I indeed misread the segfault error. It is moc, not the
compilation of moc's output as I thought.

> Regarding overwriting logs, it is Coin bug. For some reason we naively
> believed that builds are deterministic and there is only one build log
> 100 % reproducible...  Well something to fix.

Is there a JIRA for this or should I file one?

Cheers,

Sean

>
>
> Cheers,
>
>   Jędrek
>
> 
> *From:* Development
> <development-bounces+jedrzej.nowacki=qt...@qt-project.org> on behalf of
> Sean Harmer <s...@theharmers.co.uk>
> *Sent:* Sunday, October 9, 2016 9:51:47 AM
> *To:* development@qt-project.org
> *Subject:* Re: [Development] macOS CI node segfault
>
> Hi Thiago,
>
> On 08/10/2016 21:52, Thiago Macieira wrote:
>> Em sábado, 8 de outubro de 2016, às 14:44:59 CEST, Sean Harmer escreveu:
>>> Hi,
>>>
>>> Just seen another segfault on one of the mac mini CI nodes:
>>>
>>> http://testresults.qt.io/logs/qt/qt3d/8f273f12204fb46ea508393ea9ad3dcd41a498
>>> b4/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRel
>>> ease_Release/3c7a8e84853b9a3cd649d77444b6f1a885819671/buildlog.txt.gz
>>
>> Where? That log file does not contain the word "segfault", "error" or the
>> phrase "segmentation fault".
>
> Something very wrong is going on then. Look at the failed run at Oct 8
> 2:38 PM from https://codereview.qt-project.org/#/c/168122/ which is
> where I copied the link from. The report on gerrit says segmentation
> fault, as did the report when I checked it at the time, yet now indeed
> the report has no mention of a segfault at all.
>
> Sounds like something overwrote the compile report which is a little
> concerning.
>
>>
>> That said, we've known moc has been crashing on Mac for a couple of months 
>> and
>> we have no idea what's causing it.
>
> This was a segfault in the compiler when building
> .moc/release/moc_qrenderaspect.cpp rather than when running moc but I am
> suspicious of some bad RAM or something on the hardware.
>
> Cheers,
>
> Sean
> ___
> 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] macOS CI node segfault

[Jedrzej Nowacki]

As Thiago said. Moc is crashing on OSX for an unknown reason. It is unlikely to 
be RAM problem,  because we would see much wider distribution of crashes 
(related bug report: https://bugreports.qt.io/browse/QTQAINFRA-990).


Regarding overwriting logs, it is Coin bug. For some reason we naively believed 
that builds are deterministic and there is only one build log 100 % 
reproducible...  Well something to fix.


Cheers,

  J?drek


From: Development  on 
behalf of Sean Harmer 
Sent: Sunday, October 9, 2016 9:51:47 AM
To: development@qt-project.org
Subject: Re: [Development] macOS CI node segfault

Hi Thiago,

On 08/10/2016 21:52, Thiago Macieira wrote:
> Em s?bado, 8 de outubro de 2016, ?s 14:44:59 CEST, Sean Harmer escreveu:
>> Hi,
>>
>> Just seen another segfault on one of the mac mini CI nodes:
>>
>> http://testresults.qt.io/logs/qt/qt3d/8f273f12204fb46ea508393ea9ad3dcd41a498
>> b4/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRel
>> ease_Release/3c7a8e84853b9a3cd649d77444b6f1a885819671/buildlog.txt.gz
>
> Where? That log file does not contain the word "segfault", "error" or the
> phrase "segmentation fault".

Something very wrong is going on then. Look at the failed run at Oct 8
2:38 PM from https://codereview.qt-project.org/#/c/168122/ which is
where I copied the link from. The report on gerrit says segmentation
fault, as did the report when I checked it at the time, yet now indeed
the report has no mention of a segfault at all.

Sounds like something overwrote the compile report which is a little
concerning.

>
> That said, we've known moc has been crashing on Mac for a couple of months and
> we have no idea what's causing it.

This was a segfault in the compiler when building
.moc/release/moc_qrenderaspect.cpp rather than when running moc but I am
suspicious of some bad RAM or something on the hardware.

Cheers,

Sean
___
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] Module maintainers: action required (Coin migrates from sync.profile to .gitmodules on 28.09.2016)

[Jedrzej Nowacki]

Good news everyone! 

The deployment was success and we can wait for fireworks. I'm sure there will 
be some. So if something doesn't compile now, because of an invalid dependency 
look to .gitmodules in the right qt5 branch and fix it. Integrations may fail 
also because of invalid intermodule dependencies, we compile every module 
against modules from the latest successful qt5 integration of the same  branch, 
which means that we use combination of sha1 that up to now was not really 
tested, so fix it. It should be a temporary problem.

QtBase is not affected, by the change.

At this point I would like to remind everyone importance of Qt5 submodule 
updates. Breakages there are P0 for the project even in dev branch! They affect 
not only packages and release but now also our day to day development process.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Should qMetaTypeId() == qMetaTypeId()?

[Jedrzej Nowacki]

I love to be proven wrong, but this time I would not call it easy [?]  Try this:


struct F{};
Q_DECLARE_METATYPE(F*);
Q_DECLARE_METATYPE(const F*);
Q_DECLARE_METATYPE(F);
// Q_DECLARE_METATYPE(const F); doesn't compile, that is a bug!

class O : public QObject
{
Q_OBJECT
signals:
void foo1(const F*);
void foo2(F*);
};

int main(int argc, char **argv) {
qDebug() << QMetaMethod::fromSignal(::foo1).methodSignature();
qDebug() << QMetaMethod::fromSignal(::foo2).methodSignature();
return 0;
}




From: Development  on 
behalf of Olivier Goffart 
Sent: Saturday, August 27, 2016 9:30:21 AM
To: development@qt-project.org
Subject: Re: [Development] Should qMetaTypeId() == qMetaTypeId()?

On Mittwoch, 24. August 2016 16:06:50 CEST J?drzej Nowacki wrote:
> On onsdag 24. august 2016 15.23.01 CEST Marc Mutz wrote:
> > Hi,
> >
> > Currently, it's not, which doesn't make much sense, does it?
> >
> > So,
> >
> >   template 
> >   int qMetyTypeId() {
> > return qMetaTypeIdHelper::type>();
> >   }
> > ?
> >
> > (There's of course a lot more involved in this, registration should
> > discard const, too, e.g.).

I think it make sens, but it should be done at the QMetaTypeId2 Level.
We already do this for const T&, See commit
03b25125986f083a260b421abeed1f1d088d27b3
In fact, the same should be done for const T

> From C++ perspective const T and T are kind of separate types, metatype
> mimics that. QMetaType is used in many places and in some constness
> matters.
>
> Consider that example:
>  QMetaType::typeName(qMetaTypeId())
> and
>  QMetaType::typeName(qMetaTypeId())
> The function is used in metaobject to compute signatures of invokables.

I can prove you wrong easily,  both have the same result, since
QMetaType::normalizedType("const QString") == "QString"

They are different C++ type, yes,  but from a practical purpose, their use in
the metatype system is exactly the same.  You allocate, destroy or copy a
const QString the same way you do a QString.

--
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
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] Interesting CI failure: Fwd: Change in qt/qt3d[5.7]: Entity: add simple method to check for components

[Jedrzej Nowacki]

As far I remember it is our QTestlib trying hard to disconnect from attached 
debugger session on OSX. You got it because something crashed. Not related to 
CI :-)


Cheers,

  Jędrek


From: Development  on 
behalf of Thiago Macieira 
Sent: Friday, June 24, 2016 8:02:57 PM
To: development@qt-project.org
Subject: Re: [Development] Interesting CI failure: Fwd: Change in qt/qt3d[5.7]: 
Entity: add simple method to check for components

http://www.gnu.org/fun/jokes/ed-msg.html


Let's look at a typical novice's session with the mighty ed:

golem$ ed

?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
===

Note that I can't reproduce the last one. Ctrl+D quits ed for me.

(I'd seen those CI quit errors before)

On sexta-feira, 24 de junho de 2016 18:42:12 PDT Sean Harmer wrote:
> Well, that's a new one but fits quite well with the news today.
>
> Sean
>
>  Forwarded Message 
> Subject:   Change in qt/qt3d[5.7]: Entity: add simple method to check for
> components
> Date:  Fri, 24 Jun 2016 16:04:39 +
> From:  Qt CI Bot (Code Review) 
> Reply-To:  qt_ci_...@qt-project.org
> To:Paul Lemire 
> CC:Qt Sanity Bot , Sean Harmer
> , Robert Brock 
>
>
>
> Qt CI Bot has posted comments on this change.
>
> Change subject: Entity: add simple method to check for components
> ..
>
>
> Continuous Integration: Failed
>
>   Module "qt/qt3d" (3524e549c48edf4f6c90ba1e8f8af24d864b4afb) Failed
> test(s): /Users/qt/work/qt/qt3d/tests/auto/core/qaspectengine: quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   ^D
>   quit
>   Attaching to process with:
>   process attach -p 3095
>   ^D
>   ^D
>   ^D
>   ^D
>   ^D
>   ^D
>   ^D
>   ^D
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   ^D
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   ^D
>   quit
>   ^D
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   ^D
>   quit
>   ^D
>   quit
>   ^D
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   ^D
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   quit
>   quit
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   ^D
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   ^D
>   quit
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   ^D
>   ^D
>   ^D
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   ^D
>   ^D
>   quit
>   ^D
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   quit
>   ^D
>   ^D
>   quit
>   ^D
>   ^D
>   quit
>   quit
>   quit
>   ^D
>   ^D
>   ^D
>   quit
>   ^D
>   quit
>   quit
>   quit
>   quit
>   ^D
>   quProcess 3095 stopped
>   Executable module set to
> "/Users/qt/work/qt/qt3d/tests/auto/core/qaspectengine/tst_qaspectengine.app
> /Contents/MacOS/tst_qaspectengine". Architecture set to:
> x86_64-apple-macosx.
>   (lldb) quit
>   ^D
>   (lldb) quitquit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   quit
>   

Re: [Development] abandoning stale changes on gerrit

[Jedrzej Nowacki]

On Friday 1. February 2013 14.34.26 Oswald Buddenhagen wrote:
  But if we automate this the timeout period needs to be long enough.
  2-3 months is certainly too short, we need to be conservative with
  these kinds of automatisms. A year sounds more reasonable.
 
  
 
 i don't think this makes sense. i'd rather have a bot post a gentle ping
 after the proposed 3-month timeout, and then follow through within a few
 (four?) weeks.

Hi,

  That is a bit destructive. The change would be updated and filters would not 
work correctly. It is better to close them immediately, if you really need to.

Cheers,

  Jędrek

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

Re: [Development] abandoning stale changes on gerrit

[Jedrzej Nowacki]

On Wednesday 30. January 2013 12.20.18 Oswald Buddenhagen wrote:
 On Wed, Jan 30, 2013 at 08:58:32AM +0100, Jedrzej Nowacki wrote:
  Please don't do it. My dashboard contains patches, that I'm interested
  in. It is a kind of knowledge storage, with already signed CLA. I
  understand that a big dashboard is not nice to maintain, but forcing
  everyone to clean it up is not the way to go.
  
  Answer is: use filters.
  
  https://codereview.qt-project.org/#q,reviewer:+oswald+-age:+2d+status:ope
  n,n,z
  
  for more you can look here:
  https://review.typo3.org/Documentation/user-search.html
 
 thankyouverymuch, i know how to use filters.
 unfortunately, this entirely misses the point.
 the whole exercise is meant to prod some contributions into (a promise
 of) activity, and to weed out hopeless ones. most of the stuff is
 totally inapplicable meanwhile. there is just no point in keeping it
 open.
 for the repository of potentially interesting stuff [which, let's face
 it, i'll never get around to using] you can use the star feature -
 this makes it conveniently reachable, but keeps it out of your working
 set (i.e., the dashboard), and is independent of the state the changes
 are in.
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

Hi,

There is no point in closing them either. We aim for time based releases. 
There is not need for prodding. If something is not in then it is for a 
future release, or for never, which is also fine. Your work flow doesn't work, 
fine, you can go and fix it, but why in such invasive way? Sure, I can use 
star feature as well as you can use filtering. I do not see difference. 
Please, convince me that bulk abandoning will improve our lives. For now I see 
that it would improve your dashboard, by cost of everyone doing a bit of 
cleanup work.

Thank you for sharing link with the original discussion, I found reasoning why 
you believe that all changes needs to be abandon:

 - W19 - Abandon review - 3 - Is this basically to close a review after
 there has been no activity or it has been rejected? If I understand
 correctly what this is, I would give it 5, since without this the view
 of active reviews will be cluttered with old junk (basically what we
 have with merge requests today).

And Thiago's answer:

 I was thinking of withdraw a review, by the contributor, as opposed to 
close 
 it as merged by the CI system.
 
 But you're right, we need to filter out old junk of rejected reviews. There 
 shouldn't be unreviewed contributions though.

So, the goal was to __filter__ out an old junk. It seems that we do not need 
to do anything because we already have the filter feature.

Cheers,
  Jedrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] abandoning stale changes on gerrit

[Jedrzej Nowacki]

On Tuesday 29. January 2013 13.05.52 Oswald Buddenhagen wrote:
 moin *,
 
 5.0 is out and the 5.1 feature freeze isn't that far off any more.
 seems like the best time for some serious house cleaning.
 therefore i'd like to urge everyone to give their pending changes which
 haven't seen activity for a long time a honest look.
 please explicitly mark the ones you still want to work on by adding a
 comment. everything which has no indication of (planned) activity in a
 few weeks will be abandoned by administrative action.
 if you are an ex-troll/-nokian, please also check the dashboard of your
 alter ego.
 if you are a maintainer, give identified drive-by contributors a ping.
 i'd also like to encourage everyone to adopt orphaned changes they have
 an interest in.
 
 regards
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

Hi,

Please don't do it. My dashboard contains patches, that I'm interested in. It 
is a kind of knowledge storage, with already signed CLA. I understand that a 
big dashboard is not nice to maintain, but forcing everyone to clean it up is 
not the way to go. 

Answer is: use filters.

https://codereview.qt-project.org/#q,reviewer:+oswald+-age:+2d+status:open,n,z

for more you can look here:
https://review.typo3.org/Documentation/user-search.html

Cheers,

 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Iikka Eklund as approver

[Jedrzej Nowacki]

On Thursday 24. January 2013 14.49.33 Oswald Buddenhagen wrote:
  I think it's reasonable to expect that people exercise their approver
  rights with care, and only use it were appropriate.
 
 
 one would think so. but we did already see things go wrong because
 approvers made assumptions about trivial things in projects they are
 not involved in.

Hi

Oh, it is easy to invalidate such argument, I haven't seen such situation, 
so we don't work here. Stats are welcome. Anyway I took freedom of accepting 
patches in different areas. Sometimes because they were easy sometimes because 
there was no one willing to look at them. Your comment is suggesting that it 
is something wrong, but it is not. I agree with Kai we need to trust that 
people will do the right things if not... then git revert is not that hard.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ChangeLogs

[Jedrzej Nowacki]

On Thursday 17. January 2013 18.25.29 Oswald Buddenhagen wrote:
 On Thu, Jan 17, 2013 at 04:05:40PM +0100, Oswald Buddenhagen wrote:
  two more approaches have been previously proposed:
 hjk suggested yet another approach: use gerrit itself to collect the
 changelog entries. after some thinking, i came up with this process:
 - add a ChangeLog: line to the commit message as in the previous
   proposal
 - the commit-msg hook extracts and removes that line; the post-commit
   hook re-adds that line via git-notes
 - change is pushed as usual - with git-gpush (which gets extended to
   push the notes as well)
 - gerrit receives the commit and notes, creates a change, and attaches
   the changelog entry as an additional attribute to it
 - up to now, everything was an optional extension - to save the
   contributor opening the gerrit page to add a changelog entry
 - but of course, it would be possible to edit the changelog entry in the
   gui
 - the changelog entry would be approved together with the actual change.
   whether this would happen in a separate review category, with the
   stage/submit button, or something yet different, i don't know.
 - the system would require explicit action to approve the lack of a
   changelog entry
 - for final storage, changelogs would be probably re-added as git
   notes again
 - automated entry collection at release time would follow as with
   in-commit-message ChangeLog: entries
 
 the advantages of the system:
 - there is no media break like with a wiki or jira, as we use git and
   gerrit anyway
 - the commit messages themselves are not polluted
 - the changelog entries can be modified without amending and re-pushing
   the commit, thus not invalidating the actual review
 - it would be also possible to let the reviewers write the changelog
   entry (which would then have to be approved by the contributor or
   another reviewer in turn)
 - we could seamlessly switch from the in-commit-message ChangeLog:
   variant, as nothing would change in the manual steps at commit
   creation time (provided the notes-for-submission stuff would be
   implemented right away)
 the downside is rather obvious:
 - this needs to be implemented in gerrit (unless somebody already did
   something similar)
 
 this is just a step 2. it is in so far relevant, as the possibility of
 adding this later may be considered an endorsement for the original
 ChangeLog: variant.
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

I like the approach, I'm just afraid that nobody will work on patching gerrit. 
It means that in real live we will end-up with the original ChangeLog variant. 
It seems that it is the best solution anyway. 

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Interest] Re: qRegisterMetaTypeQListQSslError and type flags

[Jedrzej Nowacki]

On Thursday 3. January 2013 10.22.15 Jan Kundrát wrote:
 On Thursday, 3 January 2013 08:48:58 CEST, Jedrzej Nowacki wrote:
  It is an ODR violation detection:
  
  https://codereview.qt-project.org/#change,43812
 
 Well, the commit message says that without that change, it's possible to
 get an assert if Q_DECLARE_METATYPE(QListQSslError) is missing. My code
 doesn't include the QSslSocket header (because I wrap the socket
 implementation behind a custom class in order to work with QProcess and
 QSslSocket alike), so I hit this error now.
 
 I can easily add the Q_DECLARE_METATYPE to my code, of course, but I'm
 still wondering if the assert can be make more user-friendly (i.e. suggest
 what's going on). In addition, can the C++11's static_assert be used in
 there?
 
 With kind regards,
 Jan

Hi,
  Here is a patch making it a bit more user friendly. Feel free to review and 
add comments.
https://codereview.qt-project.org/#change,43856

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Interest] qRegisterMetaTypeQListQSslError and type flags

[Jedrzej Nowacki]

On Wednesday 2. January 2013 17.15.11 Thiago Macieira wrote:
 On quarta-feira, 2 de janeiro de 2013 16.43.27, Jan Kundrát wrote:
  QMetaType::registerType: Binary compatibility break -- Type flags for
  type 'QListQSslError' [1062] don't match. Previously registered
  TypeFlags(0x7), now registering TypeFlags(0x107).
 
 The difference is 0x100, which is
 WasDeclaredAsMetaType = 0x100
 
 Which is turned on if this hidden parameter of qRegisterNormalizedMetaType
 is true:
 
 typename QtPrivate::MetaTypeDefinedHelperT, QMetaTypeId2T::Defined 
 !QMetaTypeId2T::IsBuiltIn::DefinedType defined =
 QtPrivate::MetaTypeDefinedHelperT, QMetaTypeId2T::Defined 
 !QMetaTypeId2T::IsBuiltIn::Defined
 
 I have no clue whether the fault is in the template magic expression or
 whether the type was originally registered without being declared as a
 metatype.
 
 And even if it is the latter case, is it a problem?

It is an ODR violation detection:

https://codereview.qt-project.org/#change,43812

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Mitch Curtis for approver

[Jedrzej Nowacki]

On Friday 14. December 2012 12.05.43 Jedrzej Nowacki wrote:
 On Friday 14. December 2012 11.17.14 Jedrzej Nowacki wrote:
  14 days passed and there was no objections.
  
  Congratulations Mitch!
 
 Oops it seems that It should be 15 working days. So not yet, I will have
 set an alarm clock again... Sorry for the noise.
 
 http://qt-project.org/wiki/The_Qt_Governance_Model
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

Let's try again. 15 working days passed and there was no objections. 
Congratulations Mitch!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Mitch Curtis for approver

[Jedrzej Nowacki]

On Friday 14. December 2012 11.17.14 Jedrzej Nowacki wrote:
 14 days passed and there was no objections.
 
 Congratulations Mitch!

Oops it seems that It should be 15 working days. So not yet, I will have set 
an alarm clock again... Sorry for the noise.

http://qt-project.org/wiki/The_Qt_Governance_Model
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Comparing two reals in Qt code

[Jedrzej Nowacki]

On Friday 30. November 2012 09.23.32 Samuel Rødal wrote:
 Yep, having something similar to AlmostEqualUlpsAndAbs() would be great.
 I've had some ideas of making qFuzzyCompare work that way in the past,
 but gave them up due to not wanting to risk subtly breaking a lot of
 existing code. Introducing a new function, with default but customizable
 arguments for the max differences, sounds like the way to go.
 
 The following tasks might be relevant:
 https://bugreports.qt-project.org/browse/QTBUG-26453
 https://bugreports.qt-project.org/browse/QTBUG-16819

Hi,

   Is qFuzzyCompare compatible with ECMAScript standard for float comparision? 
It would not be good if sometimes two, const floats are equals and somtimes 
not.

Cheers,
  Jedrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Nominating Mitch Curtis for approver

[Jedrzej Nowacki]

I would like to propose Mitch Curtis for approver status.

https://codereview.qt-project.org/#q,owner:+mitch,n,z
https://codereview.qt-project.org/#dashboard,1001967

Mitch is working in the Digia Oslo office. In last few months he contributed 
more then 100 patches in different areas; mainly in documentation and date and 
time. He also put a lot of effort to triage and reproduce JIRA bugs. Lately he 
decided to explore Windows lands, and search for a dragon there. I'm sure that 
he will keep showing commitment to the Qt and interest in a clean, robust 
code.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The final mile

[Jedrzej Nowacki]

On Monday 19. November 2012 21.09.35 Knoll Lars wrote:
 The package creation time is currently being addressed, and hopefully we'll
 soon be able to get that time down to around 2-3 hours (from 7-8
 currently). In addition, I'd like to ask anybody to be careful with
 changes that might affect packaging, and to add me and Iikka as reviewers
 for changes where you suspect that packaging might be impacted

What kind of changes may affect packaging?

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Updating Serializing Qt Data Types documentation

[Jedrzej Nowacki]

On Tuesday 23. October 2012 19.34.46 Harri Porten wrote:
 On Tue, 23 Oct 2012, Mitch Curtis wrote:
  After https://codereview.qt-project.org/#change,37988, the Serializing
  Qt Data Types page lists the QDataStream version as 13. I thought it'd
  be a good idea to ask everyone who is interested to take a look and see
  if the descriptions of the data types serialised are still accurate. If
  they're not, please update the page (the path to which can be found in
  the aforementioned patch).
 
 Coincidentally we noticed a over-the-wire serialization problem today.
 With QVariant. But it's likely not an issue with above mentioned format
 version 13. Rather with a backward compat mode. Do I see it correctly that
 tests/ only cover 4.9 and 5.0 versions? Hmmm. I now realize that I can
 answer this question myself given that the coverage results we just
 posted...
 
  
 http://download.froglogic.com/public/qt5-squishcoco-report/QtBase/source_1
 43.html (see QVariant::load() and save())
 
 We'll investigate what's going on and submit a patch if it's a problem in
 QVariant or QDataStream.
 
 Harri.
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

Hi,

  I added that tests durring Qt5 development, sadly streaming was never tested 
with older versions. What is the bug, can I help somehow? Is it only Qt5 or 
Qt4 too?

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Code coverage statistics online

[Jedrzej Nowacki]

On Wednesday 26. September 2012 20.06.21 Harri Porten wrote:
 Feedback of any kind is welcome.

Nice! 

 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposing reversal of the Math3D qreal-float change

[Jedrzej Nowacki]

On Wednesday 12. September 2012 09.10.52 ext lars.kn...@nokia.com wrote:
 On Sep 12, 2012, at 12:27 AM, ext André Pönitz andre.poen...@mathematik.tu-
chemnitz.de wrote:
  On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote:
  On 11/09/2012 13:34, Thiago Macieira wrote:
  I propose we revert it.
  
  I propose we (I) fix the affected classes in QtMultimedia
  and Qt3D. I'm away on business this week but I will make a
  start asap.
  
  I believe I mentioned that before. Anyway:
  
  I think there are (medium term) only two acceptable solutions,
  none of them perfect:
  (a) keep everything as it is (or, rather, was)
  (b) have fully functional real/double verticals
 
 (c) Turn qreal into a double everywhere

I would love to kill qreal but... please go for (a). The discussion was 
already finished once with conclusion that we should not do anything about it 
for Qt5. Let's stick to the decision. The feature freeze was in February. It 
is time to release not to do major changes.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Possible binary compatibility problem in a future Qt version

[Jedrzej Nowacki]

On Wednesday 29. August 2012 14.46.17 ext Olivier Goffart wrote:
 Reviving old thread because it was discussed on IRC:
 
 On Friday 08 June 2012 10:31:31 Jedrzej Nowacki wrote:
  Hi,
  
What can go wrong then? From nothing to crash, it depends on the flag.
For
  
  example if the flag is just an optimization hint, like
  typeHasThreadSafeConstructor then it is quite safe because we could
  downgrade the registered data to a safe value, it would work, maybe a
  bit slower :-). On other hand isPointerToGObject doesn't have such safe
  value, because it points to a feature that is rather a type description.
 
 What's wrong by saying that when there are binary incompatible
 registration, we keep the maximum of flag set?  So the second registration
 which say the type is a PointerToGObject override the previous one.
 
 The code that expect PointerToGObject to be set for a given type will
 continue to work because that library should register that type.
 

Hi,

PointerToGObject is a boolean how would you say which value is supperior?

if (flags  PointerToGObject)
  storeDataInPointerContainer(object)
else
  storeDataInNormalContainer(object)

It means that the flag can change during execution of an application. I would 
say no for such solution ;-).

Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Marc Mutz for approver status

[Jedrzej Nowacki]

On Tuesday 14. August 2012 16.18.53 ext Thiago Macieira wrote:
 Hello
 
 I'd like to nominate Marc Mutz for approver status.
 
 He's been around Qt and C++ for a long time, having worked for KDAB for a
 long time. I actually don't know much of his background, I just remember
 him being there as an expert in many areas. His knowledge of C++ is
 undeniable
 
 In any case, he's been doing a lot of good work for Qt in the past few
 months, cleaning up many things like the Q_DECLARE_SHARED,
 Q_DECLARE_TYPEINFO, etc.
 
 His dashboard; https://codereview.qt-project.org/#dashboard,1000869
 And his list of accepted contributions:
 https://codereview.qt-
 project.org/#q,owner:marc.mutz%2540kdab.com+status:merged,n,z
 (there are 140 now)

Sure +1

Jedrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Q_DECLARE_TYPEINFO and namespaced Qt

[Jedrzej Nowacki]

On Wednesday 11. July 2012 02.10.28 ext Olivier Goffart wrote:
 On Tuesday 10 July 2012 18:37:20 Marc Mutz wrote:
  Hi,
  
  as seen on IRC:
  [18:18:43] ossi|tt thiago: how about we make Q_DECLARE_TYPEINFO
  automatically use the qt namespace, like Q_DECLARE_METATYPE does? it is
  massively SIC, except that probably not many outside qt/creator use it
  ... [18:20:09] marc_kdab_ ossi|tt: errhm, I used it in many projects,
  and the Q_DECLARE_METATYPE solution is also not the best one
  [18:20:22] marc_kdab_ though I'm all for consistency, too
  [18:20:34] ossi|tt marc_kdab_: but you probably didn't use qt in
  namespace? [18:21:08] marc_kdab_ could someone with VS 2005 and/or 2008
  please test-drive https://codereview.qt-project.org/#/t/35/ ?
  [18:21:42] marc_kdab_ ossi|tt: I made KDTools work with a namespaced
  Qt, and hit the problem of Q_DECLARE_TYPEINFO there
  [18:22:23] ossi|tt marc_kdab_: yeah. i'd instantly change it. not sure
  about the amount of opposition to expect, though
  [18:22:50] marc_kdab_ ossi|tt: the question is: change which way?
  [18:23:26] ossi|tt marc_kdab_: have it in the namespace transparently.
  it's insane that user code needs to be aware of this in this context
  [18:24:21] marc_kdab_ ossi|tt: but user code needs to be aware of a
  namespaced Qt in any case. Wrapping the QClass forward-declarations was
  the most work, and then wrapping Q_DECLARE_TYPEINFO, too, is just
  consistent [18:24:47] marc_kdab_ (wrapping in QT_BEGIN_NAMESPACE /
  QT_END_NAMESPACE, that is)
  [18:25:06] ossi|tt marc_kdab_: yes, but it's stupid that i need to wrap
  a macro with another macro pair
  [18:26:12] marc_kdab_ ossi|tt: depends how your take is on consistency,
  I guess [18:27:42] marc_kdab_ I don't have an opinion myself; both
  ways have pros and cons... [18:27:59] marc_kdab_ if in doubt, stay
  with the status quo, I guess [18:28:06] ossi|tt marc_kdab_: this macro
  is clearly optimized for the use in qt, where everything is wrapped in
  these macros anyway
  [18:28:35] ossi|tt marc_kdab_: the easiest way out would be
  Q_DECLARE_NAMESPACED_TYPEINFO
  
  As I said, I'm undecided. On one hand, I always have to look at the
  implementation to see whether I need to wrap the macro in
  QT_BEGIN_NAMESPACE /
  QT_END_NAMESPACE, and I would like to see consistency here, on the other
  hand, in a way it's Q_DECLARE_METATYPE that's inconsistent, since it
  violates the put Qt stuff into QT_BEGIN_NAMESPACE if you want to be
  compatible with a namespaced Qt, otherwise don't bother assumption.
  
  What's the general opinion on this?
 
 My opinion is to fix Q_DECLARE_TYPEINFO to do the same as in
 Q_DECLATE_METATYPE (as ossi says)
 
 It is source incompatible only with namespaced Qt, that are not that common
 anyway.
 
 
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

It only shows how difficult is to work with namespaced Qt :-) In general I 
agree 
with Olivier, let's fix Q_DECLARE_TYPEINFO, or just leave it as it is. I 
suspect that changing Q_DECLARE_METATYPE will have a bigger impact on source 
compatibility.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS: Javascript backend session

[Jedrzej Nowacki]

That was a nice chat, but a bit unrelated to a JavaScript backend :-)

Cheers,
 Jędrek

On Saturday 30. June 2012 15.04.27 ext Dan Leinir Turthra Jensen wrote:
 Two people did - myself and another guy whose name i unfortunately have
 forgotten. So, we sat and had a chat about Gluon's use of QtScript, and how
 we may be able to work with the V8 based QJS system, when we eventually we
 switch to Qt 5. But, really, not all that much stuff was being talked
 about there i'm afraid.
 
 On Saturday 30 June 2012 12:47:37 aurindam.j...@nokia.com wrote:
  Did anyone attend the session?
  
  From: development-bounces+aurindam.jana=nokia@qt-project.org
  [development-bounces+aurindam.jana=nokia@qt-project.org] on behalf of
  ext Donald Carr [sirsp...@gmail.com] Sent: Friday, June 29, 2012 3:38 PM
  To: development@qt-project.org
  Subject: [Development] QtCS: Javascript backend session
  
  Did anyone manage to grab notes from this session?
  
  --
  ---
  
   °v°  Donald Carr
  
  /(_)\ Vaguely Professional Penguin lover
  
   ^ ^
  
  Cave canem, te necet lingendo
  Chasing my own tail; hate to see me leave, love to watch me go
  Feeding the trolls is only marginally more rewarding than feeding the
  pigeons, and carries the same consequences
  ___
  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] Container refactor update

[Jedrzej Nowacki]

On Wednesday 20. June 2012 11.25.28 ext Peter Kümmel wrote:
 On 20.06.2012 11:09, Olivier Goffart wrote:
  static const char qt_meta_stringdata_Fooint[] = {
  
Fooint\0\0t\0asignal(int)\0
  
  };
  
  That's because you are looking at Qt4.
  In Qt5 it is could be something more like  FooT\0asignal\0\0T\0t\0
  
  And you can connect using the new pointer function syntax.
  And some little changes would be required to the other syntax for it to
  work, but it should be possible  (as now, the signature of the signal
  is only reconstructed at runtime)
  
  Fooint  foo;
  connect(foo,Fooint::asignal, this,Bar::setInt);
  connect(foo, SIGNAL(signal(int)), this, SLOT(setInt(int)));
 
 OK, connection would work. But what I mean is, from the meta type
 perspective Fooint and Foodouble would have the same meta type.
 Therefore the idea to use specialization, then you could define
 qt_meta_stringdata_Foo for each type.
 
 Peter

Just a side note. From c++ and qt meta type perspective Fooint and 
Foodouble are unrelated and completely different types. 

Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Possible binary compatibility problem in a future Qt version

[Jedrzej Nowacki]

On Friday 8. June 2012 12.31.50 ext Thiago Macieira wrote:
 On sexta-feira, 8 de junho de 2012 10.31.31, Jedrzej Nowacki wrote:
Qt meta-type system is assuming that type information is constant and
  
  consistent. It make sense because in C++ a type trait can not be changed
  during execution of an application. We agreed that unregistering of a
  type is a bad idea and that updating a type data can cause malfunction
  in Qt itself (not mentioning external library or applications). In Qt5
  we introduced a lot of template based auto-detection for different
  features. Most of the data gathered by QTypeInfo, QMetaTypeId helpers
  classes are stored in QMetaType internal data, so it can also be used
  during a runtime introspection. So far so good, we have inlined data
  which is constant and consistent with data that we stored in QMetaType.
  So what will happen if we compile an application with an older Qt and
  link against a newer one, assuming that we introduced or changed a new
  type's information?
 
 That cannot happen. A type's information cannot change incompatibly from
 one version to the next. It must stay constant until Qt 6. Take for
 example the movability flag: if a type changes from unmovable to movable,
 QList's allocation strategy might change.
 
 A type's information can only be modified by adding new traits.

Keep in mind that by introducing a new trait you are actually changing 
existing state. Imagine that we do not have movable flag. So by default 
everything is not movable. Then we introduce it, suddenly some types virtually 
change movable attribute. In this case it 98% safe, because default value is 
always valid.

 (...)
 I'd suggest that any automatic flags can only exist if they are either:
 
 a) present in Qt 5.0
 b) completely forwards and backwards compatible for all uses (something
 that might be hard to prove)

a) And bug-less... such flag can not be fixed without recompiling.
b) Such requirement makes the flag completely useless. I hope that you mean 
forward compatibility, which means that an app compiled with an older Qt 
version would work correctly with a newer Qt version.
 
 Any other flags must be user-specified, with Q_DECLARE_TYPEINFO. That way,
 we guarantee that the flag will remain the same throughout the lifetime of
 Qt 5 and that type.
 
 Changing any of the flags that can pose incompatible problems is a binary-
 incompatible change of the type itself. It must not be done if the library
 providing that type wishes to remain BC.

User-specified flags make sense, Thanks for feedback.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] About pcre in qt5

[Jedrzej Nowacki]

On Wednesday 6. June 2012 20.02.16 ext Brett Stottlemyer wrote:
 I'm hitting the same issue the QT_NO_CURSOR.  If I don't compile with this
 flag, apps crash because the cursor isn't built onto the device.  QCursor
 has no constructor when compiled with QT_NO_CURSOR, but the QMetatype seems
 to assume it is there.  That is QT_FOR_EACH_STATIC_CORE_CLASS includes
 QCursor, and the FOR_EACH crashes trying to create meta information and is
 also used to create QVariant support (which breaks without a public
 constructor as explained in the QVariant docs).

Can you share more details about the crash? QCursor support is switched off 
in QMetaType and QCursor when QT_NO_CURSOR is used.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Possible binary compatibility problem in a future Qt version

[Jedrzej Nowacki]

Hi,

  Qt meta-type system is assuming that type information is constant and 
consistent. It make sense because in C++ a type trait can not be changed 
during execution of an application. We agreed that unregistering of a type is 
a bad idea and that updating a type data can cause malfunction in Qt itself 
(not mentioning external library or applications). In Qt5 we introduced a lot 
of template based auto-detection for different features. Most of the data 
gathered by QTypeInfo, QMetaTypeId helpers classes are stored in QMetaType 
internal data, so it can also be used during a runtime introspection. So far 
so good, we have inlined data which is constant and consistent with data that 
we stored in QMetaType. So what will happen if we compile an application with 
an older Qt and link against a newer one, assuming that we introduced or 
changed a new type's information? Nothing special :-), during type 
registration old data will be registered, so again both source of type data 
would be consistent. 

  To break the current design a 3rd client of the type data has to be 
introduced. It can be Qt itself or a library linked with Qt. So lets create 
theoretical situation that we created a new type flag isPointerToGObject in 
Qt5.1. Then someone write an application that is compiled against Qt5.1 and 
use that flag with a type T that is coming from a 3rd party library compiled 
with Qt5.0. Now, if both, the application and the library register the same 
type T in Qt we will detect binary incompatible registration. It will be like 
that because the application will have different feature detection inlined code 
then the library. 

  What can go wrong then? From nothing to crash, it depends on the flag. For 
example if the flag is just an optimization hint, like 
typeHasThreadSafeConstructor then it is quite safe because we could 
downgrade the registered data to a safe value, it would work, maybe a bit 
slower :-). On other hand isPointerToGObject doesn't have such safe value, 
because it points to a feature that is rather a type description. 

  Currently we save NeedsConstruction, NeedsDestruction, MovableType, 
PointerToQObject, IsEnumeration flags. It would be great to save more in 
future, as it is really useful. Please mark that if there is a bug in code 
that detects the last two features, we will not be able to fix it until Qt6.

  What now? We can:
  1. ignore the problem as an edge case, to be honest the scenario is quite 
complex.
  2. create a policy to add only downgradable flags, so in case of problems 
we will fall-back to a safe value.
  3. start versioning types data, always access a data information with a 
special implicit marker.
  4. drop concept completely.

  I believe that only option 2 and 3 are acceptable, but I would love to know 
what you think.

Cheers,

  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development