Re: [Development] codereview, merge please

[Frederik Gladhorn]

On fredag 15. februar 2019 12:21:43 CET Martin Koller wrote:
> On Freitag, 15. Februar 2019 11:08:18 CET Andy Shaw wrote:
> > Since it has the +2 you can click on the "Merge patch 2 to staging" now,
> > is that button showing up for you?
> ah, great. Was not aware that I needed to trigger that.
> My fault. Was thinking the maintainer does that.

Thank you for contributing to Qt Martin!

This goes of course for all contributors, it's greatly appreciated that you 
make Qt better!

Sometimes Gerrit (especially the old version running on codereview.qt-
project.org) is not the most obvious to use.
For the people regularly using it, it tends to work nicely, but I can 
understand how it's just different enough from other Git workflows to be 
confusing.

Cheers,
Frederik


> Thanks!
> 
> > Andy
> > 
> > -Opprinnelig melding-
> > Fra: Development  på vegne av Martin
> > Koller  Dato: fredag 15. februar 2019 11:04
> > Til: "development@qt-project.org" 
> > Emne: [Development] codereview, merge please
> > 
> > Hi,
> > 
> > I made a patch here
> > https://codereview.qt-project.org/#/c/249171/
> > 
> > but it's still not merged.
> > Did I forget something ?




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

Re: [Development] codereview, merge please

[Martin Koller]

On Freitag, 15. Februar 2019 11:08:18 CET Andy Shaw wrote:
> Since it has the +2 you can click on the "Merge patch 2 to staging" now, is 
> that button showing up for you?

ah, great. Was not aware that I needed to trigger that.
My fault. Was thinking the maintainer does that.
Thanks!

> Andy
> 
> -Opprinnelig melding-
> Fra: Development  på vegne av Martin 
> Koller 
> Dato: fredag 15. februar 2019 11:04
> Til: "development@qt-project.org" 
> Emne: [Development] codereview, merge please
> 
> Hi,
> 
> I made a patch here
> https://codereview.qt-project.org/#/c/249171/
> 
> but it's still not merged.
> Did I forget something ?
> 
> -- 
> Best regards/Schöne Grüße
> 
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
> 
> ()  ascii ribbon campaign - against html e-mail 
> /\- against proprietary attachments
> 
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 
> 
> 


-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at


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

Re: [Development] codereview, merge please

[Andy Shaw]

Since it has the +2 you can click on the "Merge patch 2 to staging" now, is 
that button showing up for you?

Andy

-Opprinnelig melding-
Fra: Development  på vegne av Martin Koller 

Dato: fredag 15. februar 2019 11:04
Til: "development@qt-project.org" 
Emne: [Development] codereview, merge please

Hi,

I made a patch here
https://codereview.qt-project.org/#/c/249171/

but it's still not merged.
Did I forget something ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at


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


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

[Development] codereview, merge please

[Martin Koller]

Hi,

I made a patch here
https://codereview.qt-project.org/#/c/249171/

but it's still not merged.
Did I forget something ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at


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

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

[Frederik Gladhorn]

Hi,

On fredag 15. februar 2019 07:31:33 CET Lars Knoll wrote:
> Summing up the discussion here. It looks like people overall agree that the
> pinned dependency approach (option 3) sounds better than what we currently
> have. The main concern was CI capacity, but Frederik believes that with
> enough storage capacity for build artefacts this will not be worse than
> what we have today with all the failed qt5.git integrations.
 
> The only other option that was seriously considered was a more monolithic
> repo (option 4). Disadvantages here are that it would require more work on
> the CI front to make testing times bearable, and it doesn’t give us a very
> flexible approach with regards to adding/removing modules. This is
> something that option 3 will nicely give us, as it treats all repositories
> the same way. Option 3 does btw not exclude that we later on merge some
> repositories if we feel that makes sense.
 
> So let’s go with option 3. Frederik will be leading the work to get this
> implemented. 
 
> As far as I can see, it requires some changes to CI so that we have the
> dependencies encoded in each repository, a bot to automatically push sha1’s
> of dependencies forward and some monitoring to alert us if modules get left
> behind.


I have indeed been playing with this, and I think I have an implementation
that works when it comes to resolving dependencies based on the idea.

After some pondering and starting with ini files, I settled on yaml, since we 
probably want to extend the data later on and I would like this to be easily 
human and machine read- and writable.

My current files look like this:
 dependencies:
 qt/qtbase:
 ref: 698078680fc5a6870177af285fa50c0d8a7c0bc3
 url: code.qt.io
 qt/qtsvg:
 ref: 2ae3c52fc061f574c9582bf58963fb3996724fbf
 url: code.qt.io


This is for qt/qtdeclarative, sha1's taken from qt5.git at some point.
Then there is the question of what the file name should be. Should it be at 
the top-level or in a coin subdirectory? dependencies.yaml?


I have not yet worked on the bot doing the module updates (which may turn out 
to be the harder part).
I don't think this can go live before we have that written as well.

Cheers,
Frederik

 
> Cheers,
> Lars
> 
> 
> > On 30 Jan 2019, at 11:11, Edward Welbourne 
> > wrote:
> > 
> > Robin Burchell (30 January 2019 10:13)
> > 
> >> I will admit that a monorepo has a _different_ set of problems
> >> (including but not limited to: longer build times, longer test times,
> >> flaky tests in unrelated areas blocking changes),
> > 
> > 
> > It also makes it easier to cope with API changes, which is great where
> > it's public APIs that haven't yet been shipped, but also makes it easier
> > to get away with using private APIs between components that really
> > shouldn't do that.  One of the classic reasons for modularisation at the
> > VC layer is that it makes this sort of thing harder, which means it
> > happens less, which is good.
> > 
> > There's also the problem of scope - which things go in the monorepo,
> > which should be outside.  We have that today, with qt5/, and we should
> > probably hoist some of its pieces outside, if only to force ourselves to
> > make it easy for a sizeable component to live happily outside; that
> > would enable folk in our ecosystem to live happily alongside, rather
> > than inside, Qt.  If we insist on solving that as part of a switch to a
> > monorepo, then we win (even if we could have done it without the
> > switch), if only because a major upheaval is an opportunity to make
> > other needed changes.  But if we move to a monorepo without solving that
> > problem, there's a significant risk we'll be making things harder for
> > those who work outside but close to Qt.
> > 
> > 
> >> but those problems are not complex, and can be fixed with some
> >> dedicated application of smarter scripting at build/test time
> > 
> > 
> > I remain to be convinced.
> > 
> > 
> >> (for instance: if change is doc only, don't run any test that _isn't_
> >> related to documentation, to cover one complaint from earlier in this
> >> thread).
> > 
> > 
> > This sort of thing [*] sounds terribly sensible and feasible, until you
> > start running into changes that the submitter and reviewers all *think*
> > should only have impact in a bounded area, but that turns out to break
> > stuff in surprising places outside those bounds.  That's probably rare
> > but when it happens it'll gum up the works - in a seemingly not very
> > related area that's been caught in the cross-fire.  In particular, this
> > sort of thing happens more readily when disparate things use each
> > others private APIs, as sketched above.
> > 
> > [*] The case of doc fixes is probably relatively safe, of course; but if
> > this is applied to other changes, we can't be assured of as much safety.
> > One of the scripts involved in my API change review generator knows to
> > ignore various changes that "make no 

Re: [Development] Branch for Qt 6

[Edward Welbourne]

Lars Knoll (15 February 2019 09:03) wrote
> * Don’t remove any functions from wip/qt6 unless they are marked as
>   deprecated in dev or else you have discussed it on the mailing list
>   and gotten maintainer approval for the removal

To avoid conflicts on merging, when deprecating in dev and removing
from Qt6, please wait for the deprecation in dev to have merged to
wip/qt6 before turning the deprecation into removal there.

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

[Development] Code of Conduct

[Lars Knoll]

Hi everybody,

After a lot of work and discussions, I believe we have now reached consensus on 
a Code of Conduct for the Qt project. You can find the latest version on code 
review at https://codereview.qt-project.org/#/c/243623/. 

I do now consider this version as approved (it already has lots of support from 
many people), and active. However I would like to give everybody who agrees 
with the CoC a chance to add his +1 to the review so that we can show as broad 
support as possible for the CoC. Deadline for adding your +1 is Sunday, I will 
merge this on Monday (and just to be clear: we won’t do further changes on it).

I’d also like to thank everybody who has been working on it and has been 
actively involved in the discussions. A special thanks goes to the CoC working 
group and Ulf who has been doing most of the editing work. I really like the 
outcome and am very happy that we will now have that Code of Conduct in place.

Cheers,
Lars

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

Re: [Development] Proposal: New branch model

[Lars Knoll]

Lots of good discussions around the proposal from Jedrzej. It seems like this 
has been inconclusive for the moment. Both cherry-picking and the current model 
have it’s advantages and disadvantages. One major concern was that we’d 
overload especially qtbase/dev integrations and this would lead to a complete 
block in qtbase, As this is a concern already today (it’s really way too 
difficult to get a change into qtbase), I’d propose that we now first get two 
other things in place before we consider changes to how we do things here.

The first change is to implement the new module handling (see the ‘Qt modules’ 
thread).

Secondly, we need to change our CI to be able to handle multiple CI runs in 
parallel for a single repository/branch. This change is something I believe is 
required in any case (independent of the branching model to make it easier to 
land changes).

That change implies that we can have multiple staging branches that are tested 
in parallel instead of limiting ourselves to one. If a branch passes it’ll get 
merged into the target branch (unless there are conflicts). With this approach, 
we are running a minimal risk that two staging branches that are tested 
independently are not conflicting code wise, but will together cause an auto 
test regression somewhere. If that happens, we’ll find out very quickly in any 
case (because the branch will be blocked for further integrations until this is 
fixed), so I don’t think this is problematic.

There’s also a good chance that a good part of the problems we’re having with 
merges will go away once we have these two things implemented. So I’d say let’s 
do those first, see how it goes and then reconsider our branching/merging 
strategy.

Cheers,
Lars

On 10 Feb 2019, at 21:31, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

El dom., 10 feb. 2019 05:44, Sune Vuorela 
mailto:nos...@vuorela.dk>> escribió:


[snip]

I'm mostly a casual contributor, mostly dealing with fixes to bugs found
in specific releases. I'm doing my fixes in those releases. Because
that's where I need them. If I could just then push it and more or less
forget about it, that's the thing that would make it easier.

This seems to me that I need to move the fix forward to dev, then push
it, then backport it. I might not even have a dev build handy. Because
I'm basing my work on top of something released.

+1. This is the normal case for distributors (distros) and the patches we 
normally work on.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

Re: [Development] Branch for Qt 6

[Lars Knoll]

Let’s also conclude this thread. Majority consensus was that we need a branch 
and most votes went towards wip/qt6. So let’s use that for Qt 6 related work 
and create the required branch.

The following rules apply:

* We CI test the branch on (at least) a reduced set of platforms/compilers. 
Minimum is one Windows/Linux/macOS platform.
* dev gets merged into wip/qt6 on a regular basis
* Don’t remove any functions from wip/qt6 unless they are marked as deprecated 
in dev or else you have discussed it on the mailing list and gotten maintainer 
approval for the removal
* Do not break source compatibility without maintainer approval
* Breaking binary compatibility is ok
* Breaking internal API is in principle ok, but it’s the responsibility of the 
one doing the changes to help all other modules that are using that API to get 
ported. Be careful with those changes until we get the new module testing 
strategy implemented (see my other email on the Qt modules thread)

Gerrit admins, can you create the branch for qtbase? If others maintainers want 
a wip/qt6 branch for their repositories, please create those as well.

Let’s also hope that we now get the now sha1 pinning approach for module 
testing quickly to make handling of API changes across repo boundaries simpler.

Cheers,
Lars

On 16 Jan 2019, at 14:28, Shawn Rutledge 
mailto:shawn.rutle...@qt.io>> wrote:



On 16 Jan 2019, at 10:08, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:

On 16 Jan 2019, at 09:47, Alex Blasche 
mailto:alexander.blas...@qt.io>> wrote:

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Lars Knoll mailto:lars.kn...@qt.io>>
For now I’d like to limit this to qtbase, as that’s where pretty much all Qt 6 
related work happens,
and we need to do some work on the CI side to prepare the other modules for Qt 
6 related work
(Frederik will post details in a separate mail).

Lars, could you please elaborate on this point? What does for now mean? What 
time frames are we talking about?
Where does the assumption come from that all Qt 6 related work happens in 
qtbase only?

I think I know what you might want to say but the above is too absolutely 
phrased and I want the statement clear and not fuzzy. Hence please elaborate.

Currently, most of the efforts towards Qt 6 are preparations that are happening 
in qtbase, so I believe we need the branch there now, so at least some work 
start.

For other modules, we will of course also need Qt 6 related branches as soon as 
possible. But we do need to get the model on how to work in those with respect 
to our CI in order first. The problem here is that our CI makes working with 
source incompatible changes difficult between repositories. I believe we’ll 
need to fix that before we can create qt6 branches for the other repositories 
that compile and test against qtbase/qt6.

Of course you could create a wip branch for other repositories now as well to 
do Qt 6 related work that doesn’t require Qt6 related changes from qtbase.

I thought the plan before was to use version checks like

#if QT_VERSION >= QT_VERSION_CHECK(6, 0, 0)

And so we have some of those.  But it hasn’t been clear how to test them (or at 
least I didn’t take the time to figure it out).  I would have liked to start 
doing builds like that regularly a couple years ago.  We should have had a 
configure option for that already, as soon as we started doing that, IMO.

But as soon as qtbase has a qt6 branch, configure in that branch will set that 
version, and then we can build other modules and test that conditional Qt 6 
functionality, right?

As soon as we have a qt6 branch for a given module, should we start removing 
the version checks and the Qt5-specific code?  Or will we put that off until 
nearer the Qt 6 release?

Which way is going to make merges easier?

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

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