Re: [Development] Qt6 repo

[Robert Löhning via Development]

Am 23.03.2021 um 20:01 schrieb Thiago Macieira:

On Tuesday, 23 March 2021 11:32:30 PDT Nibedit Dey wrote:

Any progress on QTQAINFRA-4200 ?


You can open the link and read for yourself:

https://bugreports.qt.io/browse/QTQAINFRA-4200

There's absolutely no hurry to do this. And it needs to be synchronised with
the CI and everyone that uses the Git repositories.



Did anything happen yet?
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt6 repo

[Thiago Macieira]

On Tuesday, 23 March 2021 11:32:30 PDT Nibedit Dey wrote:
> Any progress on QTQAINFRA-4200 ?

You can open the link and read for yourself:

https://bugreports.qt.io/browse/QTQAINFRA-4200

There's absolutely no hurry to do this. And it needs to be synchronised with 
the CI and everyone that uses the Git repositories.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

Re: [Development] Qt6 repo

[Nibedit Dey]

Any progress on QTQAINFRA-4200 ?

On Tue, Jan 19, 2021 at 6:56 PM Edward Welbourne 
wrote:

> Nibedit Dey (14 January 2021 22:18) wrote:
> >>> We will wait for the Qt maintainers to take a call on this topic and
> >>> let us know the decision.
>
> On Fri, Jan 15, 2021 at 3:17 PM Edward Welbourne 
> wrote:
> >> Well, this mailing list *is* where and how the Qt maintainers make such
> >> decisions, so let's have a concrete proposal (not new, just spelled out
> >> here for the sake of concreteness):
> >>
> >> * Rename the old qt.git to qt4.git
> >> * Change anything that previously referenced qt.git to point to qt4.git
> >> * Rename qt5.git to qt.git
> >> * Retain a qt5.git symlink to qt.git on our public servers, so that
> >>those with checkouts using any of them as a remote (notably
> everyone's
> >>gerrit remote set up by init-repository) don't suffer disruption
> >> * Change all instructions for how to work on Qt development to talk
> >>about the qt.git repo
> >>
> >> The 5.* branches in qt.git will then obviously be the Qt 5 branches; the
> >> 6.* branches will equally obviously be the Qt 6 branches.  That dev is a
> >> future Qt 6 version shall be a reasonable guess, although eventually dev
> >> shall be the branch for Qt 7 development after we've released the last
> >> Qt 6 minor; but that won't make much difference to a contributor, in any
> >> case.  Once 7.* branches show up it'll be natural to suppose dev relates
> >> to them, in the same way.
> >>
> >> Then we have a simple qt.git as the super-repo for Qt, in all versions
> >> after Qt 4, alongside the repositories for all the sub-modules that get
> >> checked out under it, at least by the release team, notwithstanding that
> >> some developers may be doing other things that better suit their own
> >> workflows.
> >>
> >> At some point in the distant future, we'll be able to delete the qt5.git
> >> symlink, but we have no reason to to rush.
> >>
> >> If we are feeling really paranoid, we can split the first two steps up
> >> into
> >>
> >> * Move qt.git to qt4.git, put in place a qt.git symlink pointing to it,
> >> * Change all public mentions of qt.git to qt4.git
> >> * Wait a month, remove symlink, wait a month
>
> Robert Löhning (15 January 2021 21:00)
> > I guess a week on each side will be sufficient, but please reserve some
> > time.
>
> OK, QTQAINFRA-4200 filed.
>
> Eddy.
> ___
> 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] Qt6 repo

[Edward Welbourne]

Nibedit Dey (14 January 2021 22:18) wrote:
>>> We will wait for the Qt maintainers to take a call on this topic and
>>> let us know the decision.

On Fri, Jan 15, 2021 at 3:17 PM Edward Welbourne  wrote:
>> Well, this mailing list *is* where and how the Qt maintainers make such
>> decisions, so let's have a concrete proposal (not new, just spelled out
>> here for the sake of concreteness):
>>
>> * Rename the old qt.git to qt4.git
>> * Change anything that previously referenced qt.git to point to qt4.git
>> * Rename qt5.git to qt.git
>> * Retain a qt5.git symlink to qt.git on our public servers, so that
>>those with checkouts using any of them as a remote (notably everyone's
>>gerrit remote set up by init-repository) don't suffer disruption
>> * Change all instructions for how to work on Qt development to talk
>>about the qt.git repo
>>
>> The 5.* branches in qt.git will then obviously be the Qt 5 branches; the
>> 6.* branches will equally obviously be the Qt 6 branches.  That dev is a
>> future Qt 6 version shall be a reasonable guess, although eventually dev
>> shall be the branch for Qt 7 development after we've released the last
>> Qt 6 minor; but that won't make much difference to a contributor, in any
>> case.  Once 7.* branches show up it'll be natural to suppose dev relates
>> to them, in the same way.
>>
>> Then we have a simple qt.git as the super-repo for Qt, in all versions
>> after Qt 4, alongside the repositories for all the sub-modules that get
>> checked out under it, at least by the release team, notwithstanding that
>> some developers may be doing other things that better suit their own
>> workflows.
>>
>> At some point in the distant future, we'll be able to delete the qt5.git
>> symlink, but we have no reason to to rush.
>>
>> If we are feeling really paranoid, we can split the first two steps up
>> into
>>
>> * Move qt.git to qt4.git, put in place a qt.git symlink pointing to it,
>> * Change all public mentions of qt.git to qt4.git
>> * Wait a month, remove symlink, wait a month

Robert Löhning (15 January 2021 21:00)
> I guess a week on each side will be sufficient, but please reserve some
> time.

OK, QTQAINFRA-4200 filed.

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

Re: [Development] Qt6 repo

[Robert Löhning]

> * Wait a month, remove symlink, wait a month

I guess a week on each side will be sufficient, but please reserve some 
time.


That said: +1

Cheers,
Robert


Am 15.01.2021 um 11:50 schrieb Volker Hilsheimer:

+1, thanks Eddy.

Cheers,
Volker



On 15 Jan 2021, at 11:41, Nibedit Dey  wrote:

+1
Thank you Edward for the proposal.
It sounds good to me.

Best Regards,
Nibedit

On Fri, Jan 15, 2021 at 3:17 PM Edward Welbourne  wrote:
Nibedit Dey (14 January 2021 22:18) wrote:

Qt5 repo contains many branches and some have ambiguous names with
respect to the Qt version. e.g: It is not clear whether the dev branch
is applicable to Qt5 development or Qt6.


That ambiguity, at least, would go away if the module were called qt.git
instead of qt5.git; and we can easily do that, once we rename the old
qt.git to qt4.git (long over-due anyway), without affecting significant
numbers of people (Qt 4 is now history).


We will wait for the Qt maintainers to take a call on this topic and
let us know the decision.


Well, this mailing list *is* where and how the Qt maintainers make such
decisions, so let's have a concrete proposal (not new, just spelled out
here for the sake of concreteness):

* Rename the old qt.git to qt4.git
* Change anything that previously referenced qt.git to point to qt4.git
* Rename qt5.git to qt.git
* Retain a qt5.git symlink to qt.git on our public servers, so that
   those with checkouts using any of them as a remote (notably everyone's
   gerrit remote set up by init-repository) don't suffer disruption
* Change all instructions for how to work on Qt development to talk
   about the qt.git repo

The 5.* branches in qt.git will then obviously be the Qt 5 branches; the
6.* branches will equally obviously be the Qt 6 branches.  That dev is a
future Qt 6 version shall be a reasonable guess, although eventually dev
shall be the branch for Qt 7 development after we've released the last
Qt 6 minor; but that won't make much difference to a contributor, in any
case.  Once 7.* branches show up it'll be natural to suppose dev relates
to them, in the same way.

Then we have a simple qt.git as the super-repo for Qt, in all versions
after Qt 4, alongside the repositories for all the sub-modules that get
checked out under it, at least by the release team, notwithstanding that
some developers may be doing other things that better suit their own
workflows.

At some point in the distant future, we'll be able to delete the qt5.git
symlink, but we have no reason to to rush.

If we are feeling really paranoid, we can split the first two steps up
into

* Move qt.git to qt4.git, put in place a qt.git symlink pointing to it,
* Change all public mentions of qt.git to qt4.git
* Wait a month, remove symlink, wait a month

or insert some other time intervals in place of month, that suffice to
give a decent chance that anyone affected will trip over the change and
get their chance to catch up on what's happened, before qt.git changes
its meaning entirely.  But I doubt we need to be this paranoid.

All discussion of *what* resides in qt.git, including whether to break
out the Coin provisioning stuff to another module, is separate from this
so can be handled as a separate discussion (please change Subject).

 Eddy.
___
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 mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt6 repo

[Oswald Buddenhagen]

On Fri, Jan 15, 2021 at 10:19:56AM +, Volker Hilsheimer wrote:

On 14 Jan 2021, at 23:23, Oswald Buddenhagen  wrote:
I must have missed that. Could you share your idea again, it sounds 
great.



https://lists.qt-project.org/pipermail/development/2019-September/037465.html

FWIW, I know it’s popular to blame The Qt Company for all sorts of 
things right now,



no, it _always_ is, for good reasons.

but as I remember the discussion around dependencies.yaml, it was not 
driven by The Company at all, but by senior members and maintainers of 
the Qt community (some of which happened to be TQtC-employees at the 
time).


to me that looks like splitting hairs for the purpose of deflecting 
responsibility. tqtc is in full control of everything that relates to 
CI, so whatever happens in that area is its sole responsibility. that 
the respective devs were apparently not even formally tasked with doing 
that makes things *worse*, not better.


I would still like to understand how that particular suckfulness 
impacts the life and work of a maintainer of one of the submodules 
though.


the point is that the bot crap completely and utterly drowns out any 
actual content. even if the respective tooling can be configured to 
always filter this non-content from view, that constitutes falsifying 
history, which doesn't exactly help when reviewing merges, etc.

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

Re: [Development] Qt6 repo

[Volker Hilsheimer]

+1, thanks Eddy.

Cheers,
Volker


> On 15 Jan 2021, at 11:41, Nibedit Dey  wrote:
> 
> +1
> Thank you Edward for the proposal.
> It sounds good to me.
> 
> Best Regards,
> Nibedit
> 
> On Fri, Jan 15, 2021 at 3:17 PM Edward Welbourne  
> wrote:
> Nibedit Dey (14 January 2021 22:18) wrote:
> > Qt5 repo contains many branches and some have ambiguous names with
> > respect to the Qt version. e.g: It is not clear whether the dev branch
> > is applicable to Qt5 development or Qt6.
> 
> That ambiguity, at least, would go away if the module were called qt.git
> instead of qt5.git; and we can easily do that, once we rename the old
> qt.git to qt4.git (long over-due anyway), without affecting significant
> numbers of people (Qt 4 is now history).
> 
> > We will wait for the Qt maintainers to take a call on this topic and
> > let us know the decision.
> 
> Well, this mailing list *is* where and how the Qt maintainers make such
> decisions, so let's have a concrete proposal (not new, just spelled out
> here for the sake of concreteness):
> 
> * Rename the old qt.git to qt4.git
> * Change anything that previously referenced qt.git to point to qt4.git
> * Rename qt5.git to qt.git
> * Retain a qt5.git symlink to qt.git on our public servers, so that
>   those with checkouts using any of them as a remote (notably everyone's
>   gerrit remote set up by init-repository) don't suffer disruption
> * Change all instructions for how to work on Qt development to talk
>   about the qt.git repo
> 
> The 5.* branches in qt.git will then obviously be the Qt 5 branches; the
> 6.* branches will equally obviously be the Qt 6 branches.  That dev is a
> future Qt 6 version shall be a reasonable guess, although eventually dev
> shall be the branch for Qt 7 development after we've released the last
> Qt 6 minor; but that won't make much difference to a contributor, in any
> case.  Once 7.* branches show up it'll be natural to suppose dev relates
> to them, in the same way.
> 
> Then we have a simple qt.git as the super-repo for Qt, in all versions
> after Qt 4, alongside the repositories for all the sub-modules that get
> checked out under it, at least by the release team, notwithstanding that
> some developers may be doing other things that better suit their own
> workflows.
> 
> At some point in the distant future, we'll be able to delete the qt5.git
> symlink, but we have no reason to to rush.
> 
> If we are feeling really paranoid, we can split the first two steps up
> into
> 
> * Move qt.git to qt4.git, put in place a qt.git symlink pointing to it,
> * Change all public mentions of qt.git to qt4.git
> * Wait a month, remove symlink, wait a month
> 
> or insert some other time intervals in place of month, that suffice to
> give a decent chance that anyone affected will trip over the change and
> get their chance to catch up on what's happened, before qt.git changes
> its meaning entirely.  But I doubt we need to be this paranoid.
> 
> All discussion of *what* resides in qt.git, including whether to break
> out the Coin provisioning stuff to another module, is separate from this
> so can be handled as a separate discussion (please change Subject).
> 
> Eddy.
> ___
> 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] Qt6 repo

[Nibedit Dey]

+1
Thank you Edward for the proposal.
It sounds good to me.

Best Regards,
Nibedit

On Fri, Jan 15, 2021 at 3:17 PM Edward Welbourne 
wrote:

> Nibedit Dey (14 January 2021 22:18) wrote:
> > Qt5 repo contains many branches and some have ambiguous names with
> > respect to the Qt version. e.g: It is not clear whether the dev branch
> > is applicable to Qt5 development or Qt6.
>
> That ambiguity, at least, would go away if the module were called qt.git
> instead of qt5.git; and we can easily do that, once we rename the old
> qt.git to qt4.git (long over-due anyway), without affecting significant
> numbers of people (Qt 4 is now history).
>
> > We will wait for the Qt maintainers to take a call on this topic and
> > let us know the decision.
>
> Well, this mailing list *is* where and how the Qt maintainers make such
> decisions, so let's have a concrete proposal (not new, just spelled out
> here for the sake of concreteness):
>
> * Rename the old qt.git to qt4.git
> * Change anything that previously referenced qt.git to point to qt4.git
> * Rename qt5.git to qt.git
> * Retain a qt5.git symlink to qt.git on our public servers, so that
>   those with checkouts using any of them as a remote (notably everyone's
>   gerrit remote set up by init-repository) don't suffer disruption
> * Change all instructions for how to work on Qt development to talk
>   about the qt.git repo
>
> The 5.* branches in qt.git will then obviously be the Qt 5 branches; the
> 6.* branches will equally obviously be the Qt 6 branches.  That dev is a
> future Qt 6 version shall be a reasonable guess, although eventually dev
> shall be the branch for Qt 7 development after we've released the last
> Qt 6 minor; but that won't make much difference to a contributor, in any
> case.  Once 7.* branches show up it'll be natural to suppose dev relates
> to them, in the same way.
>
> Then we have a simple qt.git as the super-repo for Qt, in all versions
> after Qt 4, alongside the repositories for all the sub-modules that get
> checked out under it, at least by the release team, notwithstanding that
> some developers may be doing other things that better suit their own
> workflows.
>
> At some point in the distant future, we'll be able to delete the qt5.git
> symlink, but we have no reason to to rush.
>
> If we are feeling really paranoid, we can split the first two steps up
> into
>
> * Move qt.git to qt4.git, put in place a qt.git symlink pointing to it,
> * Change all public mentions of qt.git to qt4.git
> * Wait a month, remove symlink, wait a month
>
> or insert some other time intervals in place of month, that suffice to
> give a decent chance that anyone affected will trip over the change and
> get their chance to catch up on what's happened, before qt.git changes
> its meaning entirely.  But I doubt we need to be this paranoid.
>
> All discussion of *what* resides in qt.git, including whether to break
> out the Coin provisioning stuff to another module, is separate from this
> so can be handled as a separate discussion (please change Subject).
>
> Eddy.
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt6 repo

[Volker Hilsheimer]

> On 14 Jan 2021, at 23:23, Oswald Buddenhagen  
> wrote:
> 
> On Thu, Jan 14, 2021 at 02:08:43PM +, Volker Hilsheimer wrote:
>> Nevertheless, federating the declaration of the dependencies across modules 
>> out to each module is the right idea, I think.
>> 
> no, it's not. for tightly bound co-evolving packages, the vcs should provide 
> as much atomicity as reasonably possible.
> 
>> It's tradeoff is between (eventual) consistency that allows us to declare a 
>> release that includes all packages, and not making a centralized .gitmodules 
>> file the bottleneck. The 5 step process that required the qt5.git 
>> integrations to succeed twice to make trivial changes in private APIs that 
>> were used across modules, is not something I think we want back either.
>> 
> you're setting up a false dichotomy. i've described how to do it properly 
> with only .gitmodules before the .yaml crap went into full production, but 
> tqtc was (as usual) more interested in protecting a prior investment than 
> doing things right.


Hey Ossi,

I must have missed that. Could you share your idea again, it sounds great.

FWIW, I know it’s popular to blame The Qt Company for all sorts of things right 
now, but as I remember the discussion around dependencies.yaml, it was not 
driven by The Company at all, but by senior members and maintainers of the Qt 
community (some of which happened to be TQtC-employees at the time).


> and yes, it *is* crap. run gitk --all in any non-central module and tell me 
> with a straight face that what you're seeing doesn't suck big time.  yes, as 
> the maintainer of qttranslations i have to deal with that on a (somewhat) 
> regular basis.


Since I’m on macOS I don’t use (or have) “gitk” or any equivalent tool, and 
even if I could “brew install” it, I probably won't care as much for the 
aesthetics of the visualised git history as you do. So, I’ll trust you that it 
sucks big time.

I would still like to understand how that particular suckfulness impacts the 
life and work of a maintainer of one of the submodules though.


Cheers,
Volker


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

Re: [Development] Qt6 repo

[Edward Welbourne]

Nibedit Dey (14 January 2021 22:18) wrote:
> Qt5 repo contains many branches and some have ambiguous names with
> respect to the Qt version. e.g: It is not clear whether the dev branch
> is applicable to Qt5 development or Qt6.

That ambiguity, at least, would go away if the module were called qt.git
instead of qt5.git; and we can easily do that, once we rename the old
qt.git to qt4.git (long over-due anyway), without affecting significant
numbers of people (Qt 4 is now history).

> We will wait for the Qt maintainers to take a call on this topic and
> let us know the decision.

Well, this mailing list *is* where and how the Qt maintainers make such
decisions, so let's have a concrete proposal (not new, just spelled out
here for the sake of concreteness):

* Rename the old qt.git to qt4.git
* Change anything that previously referenced qt.git to point to qt4.git
* Rename qt5.git to qt.git
* Retain a qt5.git symlink to qt.git on our public servers, so that
  those with checkouts using any of them as a remote (notably everyone's
  gerrit remote set up by init-repository) don't suffer disruption
* Change all instructions for how to work on Qt development to talk
  about the qt.git repo

The 5.* branches in qt.git will then obviously be the Qt 5 branches; the
6.* branches will equally obviously be the Qt 6 branches.  That dev is a
future Qt 6 version shall be a reasonable guess, although eventually dev
shall be the branch for Qt 7 development after we've released the last
Qt 6 minor; but that won't make much difference to a contributor, in any
case.  Once 7.* branches show up it'll be natural to suppose dev relates
to them, in the same way.

Then we have a simple qt.git as the super-repo for Qt, in all versions
after Qt 4, alongside the repositories for all the sub-modules that get
checked out under it, at least by the release team, notwithstanding that
some developers may be doing other things that better suit their own
workflows.

At some point in the distant future, we'll be able to delete the qt5.git
symlink, but we have no reason to to rush.

If we are feeling really paranoid, we can split the first two steps up
into

* Move qt.git to qt4.git, put in place a qt.git symlink pointing to it,
* Change all public mentions of qt.git to qt4.git
* Wait a month, remove symlink, wait a month

or insert some other time intervals in place of month, that suffice to
give a decent chance that anyone affected will trip over the change and
get their chance to catch up on what's happened, before qt.git changes
its meaning entirely.  But I doubt we need to be this paranoid.

All discussion of *what* resides in qt.git, including whether to break
out the Coin provisioning stuff to another module, is separate from this
so can be handled as a separate discussion (please change Subject).

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

Re: [Development] Qt6 repo

[Oswald Buddenhagen]

On Thu, Jan 14, 2021 at 02:08:43PM +, Volker Hilsheimer wrote:
Nevertheless, federating the declaration of the dependencies across 
modules out to each module is the right idea, I think.


no, it's not. for tightly bound co-evolving packages, the vcs should 
provide as much atomicity as reasonably possible.


It's tradeoff is between (eventual) consistency that allows us to 
declare a release that includes all packages, and not making a 
centralized .gitmodules file the bottleneck. The 5 step process that 
required the qt5.git integrations to succeed twice to make trivial 
changes in private APIs that were used across modules, is not something 
I think we want back either.


you're setting up a false dichotomy. i've described how to do it 
properly with only .gitmodules before the .yaml crap went into full 
production, but tqtc was (as usual) more interested in protecting a 
prior investment than doing things right.


and yes, it *is* crap. run gitk --all in any non-central module and tell 
me with a straight face that what you're seeing doesn't suck big time.  
yes, as the maintainer of qttranslations i have to deal with that on a 
(somewhat) regular basis.

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

Re: [Development] Qt6 repo

[Nibedit Dey]

Thank you again everyone for the suggestions.
Most people have agreed that there is a need for simplifying the repo
nomenclature, build system, and scripts. This will attract contributions
from more Qt developers. People who have been using Qt for years are
familiar with the submodules, and the scripts. However, when a new person
tries to contribute, they often get confused with the existing complexities.

Adding inputs from Andy and Volker below:

Andy Nichols :





*"So let's have the discussion then. Qt is already ridiculously hard to
build and contribute to for new-commers not already well acquainted with
the arcane knowledge without additional silliness like this.  Qt 6 has been
released, so it's a bit ridiculous at this point to still point
contributors at the qt5.git super module to contribute to Qt 6.qt = qt4qt5
= qt5 and qt6 (depends on branch).We could come up with a solution that
avoids this.  Why not just have a new supermodule specifically for Qt6 or
for even lower effort have an alias repo called qt6.  It's such a small
thing in practice, but it causes unnecessary confusion for those not
already in-the-know."*

Volker Hilsheimer:

*"Given that there’ll be a Qt 7 and Qt 8, and perhaps not only after 7
years, I’d prefer a “qt. git” which contains only the .gitmodules file
(plus needed LICENSE files), and whatever “bootstrapping” script and README
we want to help with our somewhat special git setup (gerrit specific hooks;
our commit templates; ssh configuration since our gerrit server listens on
port 29418, and requires a special cypher to be used; that we want people
to pull from code.qt.io  rather than from gerrit; etc).*

*I don’t quite understand why all those Qt 5 branches will confuse people;
if you look for branches, use grep or whatever. So, I’d rather rename
today’s qt.git to qt4.git, and qt5.git to qt.git. Or as a second option
rename qt.git to qt4.git and then start with a fresh qt.git."*

Qt5 repo contains many branches and some have ambiguous names with respect
to the Qt version. e.g: It is not clear whether the *dev *branch is
applicable to Qt5 development or Qt6. Since Qt6 is a major change with the
removal of obsolete modules, there can be confusion while submitting bug
fixes. When Qt7 comes and Qt5 officially gets abandoned, then people who
want to use Qt5 can still keep it maintained without creating further
confusion.

We will wait for the Qt maintainers to take a call on this topic and let us
know the decision.

Best Regards,
Nibedit

On Thu, Jan 14, 2021 at 12:51 PM Nibedit Dey  wrote:

> Thank you everyone for the suggestions.
> I posted in the development group as there was less participation on the
> topic in the interest group.
> Below are my suggestions:
>
>- Create a clean qt6 supermodule for better maintainability. It's
>still not too late.
>- If the qt5 supermodule is renamed, then it will still have many qt5
>branches. This may create confusion while looking for specific branches.
>- The use of a script is a good idea, but it needs to be mentioned in
>the README document. Else new Qt developer or contributors may face
>difficulties while building from source.
>
> Any thoughts?
>
> Best Regards,
> Nibedit
>
> On Wed, Jan 13, 2021 at 4:06 PM Nibedit Dey  wrote:
>
>> Hello Everyone,
>>
>> Is there any plan to move the qt6 source code to a different repo (qt6)?
>> Currently, the branch lies inside the qt5 repo.
>> Is there going to be a Qt6 super module in near future?
>>
>> Thanks & Regards,
>> Nibedit
>>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt6 repo

[Volker Hilsheimer]

> On 14 Jan 2021, at 16:12, Thiago Macieira  wrote:
> 
> On Thursday, 14 January 2021 06:08:43 PST Volker Hilsheimer wrote:
>>> Same here. Please refrain from cooking up our own git submodule
>>> replacement soup.
>> 
>> Hm, but dependencies.yaml already *is* our own “git submodule replacement
>> soup”, to some degree, isn’t it?
> 
> Not if I don't care about the dependency. If I am making a change to a given 
> module, I *must* test its tip. Moreover, I should expect that the dependency 
> on other modules has moved by the time my change gets tested in the CI, so I 
> should also be testing against the dependencies' branch tips.
> 
> The dependency.yaml file is good for the CI so it doesn't introduce breakages 
> in leaf modules until they get fixed. But for *development*, it isn't useful. 
> It's actually detrimental.


Indeed, always work on the tip of the module you make changes in. But that 
doesn’t mean that you have to work on the tip of all the modules it depends on 
as well. Although I’m a very much in favour of doing so as much as possible.

I always try to work with HEAD of everything, in the dev branch, and it works 
most of the time these days. It very frequently didn’t work during Qt 6 
development, with both builds and behavior breakages. But I’d rather have us 
know about those breakages early and make it a priority to fix them, because at 
some point someone will have to fix them anyway. So the sooner, the better - 
for a complex system, mean time to recovery is MUCH more important than mean 
time between failure.

But sometimes it’s not feasible; there might be no point in waiting for hours 
or days until someone else’s fix is ready. Then being able to go quickly back 
to the qtbase or qtdeclarative revision that e.g. qtquickcontrols2 was last 
successfully tested with is useful, and that’s what a check-out based on 
dependencies.yaml allows me to do.


>> Nevertheless, federating the declaration of the dependencies across modules
>> out to each module is the right idea, I think. It's tradeoff is between
>> (eventual) consistency that allows us to declare a release that includes
>> all packages, and not making a centralized .gitmodules file the bottleneck.
>> The 5 step process that required the qt5.git integrations to succeed twice
>> to make trivial changes in private APIs that were used across modules, is
>> not something I think we want back either.
> 
> We should stop using private APIs to this extent.
> If some module needs private API and is not a tight integration like QML is 
> to 
> QObject, that's a red flag that the API should be public in the first place.
> 
> (QObjectPrivate inheritance is usually source-compatible)


It’s an ideal state that we are very far away from, I think. Perhaps another 
way to look at it is: IF we have tight integrations across modules on private 
API level, then they should be in the same repository (qtdeclarative and 
qtquickcontrols2 might be a candidate for that consideration)?

But it’s not just APIs anyway, compile breakages would at least be easy to 
discover locally so that the follow-up changes to leaf modules can be ready. 
Behavior changes like the event refactoring we did for Qt 6 are much more 
messy, because so much of our tests can’t be meaningfully run on a local 
workstation, esp across platforms.


>> Take away: .gitmodules and dependencies.yaml can and need to coexist.
>> Neither will work for everybody.
> 
> I actually agree.
> 
>> The only problem that remains is that the top-level build system lives in
>> the super module, forcing people that want to use that build system
>> together with worktrees to hack around the mess. If we can solve that by
>> moving the build system out as part of establishing a qt6.git or whatever
>> we end up with, then I’m a happy camper.
> 
> The top-level buildsystem is optional. If it can be replaced by a single 
> small 
> CMakeLists.txt or a shell script or hand-written Makefile, we should do it.

It’s all that already, just in the wrong place (for me and my love of 
worktrees) :)

Cheers,
Volker



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

Re: [Development] Qt6 repo

[Thiago Macieira]

On Thursday, 14 January 2021 01:50:57 PST Volker Hilsheimer wrote:
> $ ninja tst_class_I_fixed_check
> 
> and ninja rebuilding everything that needs to be rebuilt across all modules
> before running the test is a huge timesaver.

And I learnt yesterday:

$ ctest -L cbor
Test project /home/tjmaciei/obj/qt/qt6/qtbase
Start 107: tst_qcborstreamreader
1/4 Test #107: tst_qcborstreamreader    Passed0.78 sec
Start 108: tst_qcborstreamwriter
2/4 Test #108: tst_qcborstreamwriter    Passed0.04 sec
Start 109: tst_qcborvalue
3/4 Test #109: tst_qcborvalue ...   Passed0.09 sec
Start 110: tst_qcborvalue_json
4/4 Test #110: tst_qcborvalue_json ..   Passed0.02 sec

100% tests passed, 0 tests failed out of 4

Label Time Summary:
tests/auto/corelib/serialization/qcborstreamreader/tst_qcborstreamreader=   
0.78 sec*proc (1 test)
tests/auto/corelib/serialization/qcborstreamwriter/tst_qcborstreamwriter=   
0.04 sec*proc (1 test)
tests/auto/corelib/serialization/qcborvalue/tst_qcborvalue  =   
0.09 sec*proc (1 test)
tests/auto/corelib/serialization/qcborvalue_json/tst_qcborvalue_json=   
0.02 sec*proc (1 test)

Total Test time (real) =   0.98 sec

Now if only ctest integrated with cmake and built the targets before trying to 
run them...

$ ctest -L serialization
Test project /home/tjmaciei/obj/qt/qt6/qtbase
Start 106: tst_json
1/9 Test #106: tst_json .***Failed0.01 sec
Start 107: tst_qcborstreamreader
2/9 Test #107: tst_qcborstreamreader    Passed0.69 sec
Start 108: tst_qcborstreamwriter
3/9 Test #108: tst_qcborstreamwriter    Passed0.04 sec
Start 109: tst_qcborvalue
4/9 Test #109: tst_qcborvalue ...   Passed0.08 sec
Start 110: tst_qcborvalue_json
5/9 Test #110: tst_qcborvalue_json ..   Passed0.01 sec
Start 111: tst_qdatastream
6/9 Test #111: tst_qdatastream ..***Failed0.01 sec
Start 112: tst_qdatastream_core_pixmap
7/9 Test #112: tst_qdatastream_core_pixmap ..***Failed0.00 sec
Start 113: tst_qtextstream
8/9 Test #113: tst_qtextstream ..***Failed0.00 sec
Start 114: tst_qxmlstream
9/9 Test #114: tst_qxmlstream ...***Failed0.00 sec

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

Re: [Development] Qt6 repo

[Thiago Macieira]

On Thursday, 14 January 2021 06:08:43 PST Volker Hilsheimer wrote:
> > Same here. Please refrain from cooking up our own git submodule
> > replacement soup.
> 
> Hm, but dependencies.yaml already *is* our own “git submodule replacement
> soup”, to some degree, isn’t it?

Not if I don't care about the dependency. If I am making a change to a given 
module, I *must* test its tip. Moreover, I should expect that the dependency 
on other modules has moved by the time my change gets tested in the CI, so I 
should also be testing against the dependencies' branch tips.

The dependency.yaml file is good for the CI so it doesn't introduce breakages 
in leaf modules until they get fixed. But for *development*, it isn't useful. 
It's actually detrimental.
 
> Nevertheless, federating the declaration of the dependencies across modules
> out to each module is the right idea, I think. It's tradeoff is between
> (eventual) consistency that allows us to declare a release that includes
> all packages, and not making a centralized .gitmodules file the bottleneck.
> The 5 step process that required the qt5.git integrations to succeed twice
> to make trivial changes in private APIs that were used across modules, is
> not something I think we want back either.

We should stop using private APIs to this extent.

If some module needs private API and is not a tight integration like QML is to 
QObject, that's a red flag that the API should be public in the first place.

(QObjectPrivate inheritance is usually source-compatible)
 
> Take away: .gitmodules and dependencies.yaml can and need to coexist.
> Neither will work for everybody.

I actually agree.
 
> The only problem that remains is that the top-level build system lives in
> the super module, forcing people that want to use that build system
> together with worktrees to hack around the mess. If we can solve that by
> moving the build system out as part of establishing a qt6.git or whatever
> we end up with, then I’m a happy camper.

The top-level buildsystem is optional. If it can be replaced by a single small 
CMakeLists.txt or a shell script or hand-written Makefile, we should do it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

Re: [Development] Qt6 repo

[Thiago Macieira]

On Thursday, 14 January 2021 01:28:46 PST Christian Kandeler wrote:
> On 1/13/21 11:46 PM, Thiago Macieira wrote:
> > Like I said above, the latest tip of the branch for every single
> > module. This
> > recipe has worked for me for 10 years.
> 
> I don't believe you.

It has.

Just one detail: I've only used the stable branch only for the last 10 years, 
except for a brief period between the .1 of the previous release and the new 
release's branching.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

Re: [Development] Qt6 repo

[Volker Hilsheimer]

> On 14 Jan 2021, at 08:21, Nibedit Dey  wrote:
> 
> Thank you everyone for the suggestions.
> I posted in the development group as there was less participation on the 
> topic in the interest group.
> Below are my suggestions:
>   • Create a clean qt6 supermodule for better maintainability. It's still 
> not too late.
>   • If the qt5 supermodule is renamed, then it will still have many qt5 
> branches. This may create confusion while looking for specific branches.
>   • The use of a script is a good idea, but it needs to be mentioned in 
> the README document. Else new Qt developer or contributors may face 
> difficulties while building from source.
> Any thoughts?
> 

Given that there’ll be a Qt 7 and Qt 8, and perhaps not only after 7 years, I’d 
prefer a “qt.git” which contains only the .gitmodules file (plus needed LICENSE 
files), and whatever “bootstrapping” script and README we want to help with our 
somewhat special git setup (gerrit specific hooks; our commit templates; ssh 
configuration since our gerrit server listens on port 29418, and requires a 
special cypher to be used; that we want people to pull from code.qt.io rather 
than from gerrit; etc).

I don’t quite understand why all those Qt 5 branches will confuse people; if 
you look for branches, use grep or whatever. So, I’d rather rename today’s 
qt.git to qt4.git, and qt5.git to qt.git. Or as a second option rename qt.git 
to qt4.git and then start with a fresh qt.git.


Cheers,
Volker


> Best Regards,
> Nibedit
> 
> On Wed, Jan 13, 2021 at 4:06 PM Nibedit Dey  wrote:
> Hello Everyone,
> 
> Is there any plan to move the qt6 source code to a different repo (qt6)? 
> Currently, the branch lies inside the qt5 repo.
> Is there going to be a Qt6 super module in near future?
> 
> Thanks & Regards,
> Nibedit
> ___
> 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] Qt6 repo

[Volker Hilsheimer]

> On 14 Jan 2021, at 13:50, Joerg Bornemann  wrote:
> 
> On 1/13/21 5:28 PM, Thiago Macieira wrote:
>> On Wednesday, 13 January 2021 05:37:21 PST Volker Hilsheimer wrote:
>>> * stop using git submodules
>>> 
>>> Using them serves no real purposes anymore. We anyway have our own scripting
>>> in form of init-repository to avoid that people have to deal with that
>>> stuff.
>> Please don't. In fact, I recommend the opposite: delete the Perl script and
>> use submodules properly.
>> I do use "git pull --recurse-submodules", "git submodule update", "git
>> submodule foreach", etc. often.
> 
> Same here. Please refrain from cooking up our own git submodule replacement 
> soup.

Hm, but dependencies.yaml already *is* our own “git submodule replacement 
soup”, to some degree, isn’t it?

You are all correct in pointing out that my case is too simplistic, thanks for 
that. There evidently are cases where multiple unrelated repos depending on 
e.g. qtbase can cause problems if all we have are dependencies.yaml files. And 
yes, .gitmodules provides what we need for those cases, so I retract my 
statement that we can perhaps get rid of it.

Nevertheless, federating the declaration of the dependencies across modules out 
to each module is the right idea, I think. It's tradeoff is between (eventual) 
consistency that allows us to declare a release that includes all packages, and 
not making a centralized .gitmodules file the bottleneck. The 5 step process 
that required the qt5.git integrations to succeed twice to make trivial changes 
in private APIs that were used across modules, is not something I think we want 
back either.

Take away: .gitmodules and dependencies.yaml can and need to coexist. Neither 
will work for everybody.

The only problem that remains is that the top-level build system lives in the 
super module, forcing people that want to use that build system together with 
worktrees to hack around the mess. If we can solve that by moving the build 
system out as part of establishing a qt6.git or whatever we end up with, then 
I’m a happy camper.

So, thanks for adding your perspectives to the discussion, it’s been 
educational.

Volker

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

Re: [Development] Qt6 repo

[Joerg Bornemann]

On 1/13/21 5:28 PM, Thiago Macieira wrote:

On Wednesday, 13 January 2021 05:37:21 PST Volker Hilsheimer wrote:

* stop using git submodules

Using them serves no real purposes anymore. We anyway have our own scripting
in form of init-repository to avoid that people have to deal with that
stuff.


Please don't. In fact, I recommend the opposite: delete the Perl script and
use submodules properly.

I do use "git pull --recurse-submodules", "git submodule update", "git
submodule foreach", etc. often.


Same here. Please refrain from cooking up our own git submodule 
replacement soup.



Cheers,

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

Re: [Development] Qt6 repo

[Eike Ziller]

> On Jan 14, 2021, at 11:08, Volker Hilsheimer  wrote:
> 
>> On 13 Jan 2021, at 22:58, André Pönitz  wrote:
>> 
>> On Wed, Jan 13, 2021 at 12:48:45PM -0800, Thiago Macieira wrote:
>>> On Wednesday, 13 January 2021 10:17:02 PST André Pönitz wrote:
 I have a product that depends on qtbase, qtdeclarative and qttool, and
 qtdeclarative and qttools refer to different and incompatible versions
 of qtbase in their respective dependency.yaml files.
 
 How do I build Qt?
>>> 
>>> There's no such thing.
>> 
>> You are telling me my day job doesn't exist?
>> 
>>> Any *product* is built with released versions of Qt, which means you
>>> must have exactly the same releases of each module. No other
>>> combination is supported.
>> 
>> I am not asking for *support*. I am asking how to find a recent working
>> combination of Qt modules that I need for porting some code base to
>> Qt 6. Don't tell me to use 6.0 nor to wait for some 6.x.
> 
> Our CI system should prevent that a change to a dependency.yaml file merges 
> that results in multiple dependencies to several conflicting versions of any 
> upstream library.

That might be, but ...

> 
> If a change to qttools/dependencies.yaml file adds a dependency to 
> qtdeclarative:A and qtbase:B, but qtdeclarative:A depends on qtbase:A, then 
> your change won’t merge (Coin will fail during provisioning).

In case of modules that are in a single dependency chain (qttools, 
qtdeclarative and qtbase) you can still find working SHAs by using the “leaf” 
qttools as a base.
If you now add another module (e.g. qt5compat), this can then require a 
different qtbase SHA to build.

Exactly this situation occurred multiple times to me during (even late) Qt6 
development.
qt5.git integrations are the only “guaranteed” collection of SHAs that build.

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt6 repo

[Alex Blasche]

> -Original Message-
> From: Development  On Behalf Of
> Volker Hilsheimer

> > I am not asking for *support*. I am asking how to find a recent
> > working combination of Qt modules that I need for porting some code
> > base to Qt 6. Don't tell me to use 6.0 nor to wait for some 6.x.
> 
> Our CI system should prevent that a change to a dependency.yaml file merges
> that results in multiple dependencies to several conflicting versions of any
> upstream library.
> 
> If a change to qttools/dependencies.yaml file adds a dependency to
> qtdeclarative:A and qtbase:B, but qtdeclarative:A depends on qtbase:A, then
> your change won’t merge (Coin will fail during provisioning).

This is a very simplistic way and I can understand why you might think it works 
for you. However, the further you get in the dependency chain the more complex 
your chain is. You gave a nice linear dependency in your example. Imagine you 
have a diamond dependency (e.g. when you checkout webengine):

qtmodulefoo -> qtdeclarative -> qtbase
-> qtmodulebar -> qtbase

You approach does not work here. If you make a commit to foo, bar and 
declarative have a different dependency to qtbase you will find two chains 
which might be incompatible. The CI will detect it but the effort to keep every 
module you depend on in sync is huge the further you are away from qtbase. 


 > >> For people developing Qt, once you've checked the Git repositories
> >> out, it doesn't matter whether there's a .gitmodules or not to build.
> >
> > Lacking a monolothic repo the superrepo is currently pretty much the
> > only safe way to find a working combination of reasonably recent
> > states of Qt modules. Sure, one can try HEAD of each module first, and
> > it works sometimes. In a few more cases commenting out a few unneeded
> > bits helps to make it work, but after the third attempt one wants a safe 
> > fall
> back.
> > So far the superrepo delivers that.
> 
> 
> So does the chain of dependencies.yaml files. If the above Coin process 
> works, it
> results in a consistent set of dependencies. The closer you are to qtbase, the
> closer to HEAD your qtbase will probably be. If you want to work on a module
> far down the dependency tree, your qtbase might be older because not all
> dependencies have been updated.

Sadly the set is not consistent. To get a build for foo I might first have to 
push either declarative or bar ahead first. Since the dependency of foo and 
declarative is set independently from each other, chances are they will always 
be out of sync. Especially the less active bar repo will always lack behind. As 
a matter of fact, even if the qtbase SHA's for foo and declarative are 
compatible, the scripts simple SHA checking won't detect it. 

This means a release team will face challenges finding a releasable set of 
SHA's across the modules. To make a decent release you have to face 
synchronizing SHAs in 20 git modules while a common supermodule will do this in 
one set. The trouble of making everything work like a qt5.git update won't 
disappear but is much harder because you have to deal with 20 commits across 
the git module. 

 
> git submodules only updates if everything works. That’s not useful if you
> primarily work on qtdeclarative, so only depend on qtbase (and yes, we want
> people working on qtdeclarative to test their changes against e.g.
> qtquickcontrols2 as well; but I hope you get my point).

*If* you work on declarative you suggestion is fine. qt5.git is not for this 
usecase anyway. It is for a common release. Qt5.git is not for that but for a 
release team or first time user who looks at a complete releasable/usable set 
of SHA's at a given time. One qt5.git update will do that. Your approach 
requires multiple checkouts across several modules behind some magic script. 

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

Re: [Development] Qt6 repo

[Edward Welbourne]

Volker Hilsheimer (14 January 2021 10:50) wrote:
> The init-repository script does some extra work that is supposed to
> give people a leg up though, such as setting up commit hooks and
> remotes in all submodules.

It also provides mechanisms for selecting what set of modules you want
checked out.  This means that I can, in my qt5/dev checkout, have a
promiscuous selection of modules while, in each qt5/n.m checkout, I have
n.m's essential, preview and addon modules checked out, based on
init-repository's reading of n.m's .gitmodules files.  I could surely do
that using work-trees, all based off my primary qt5/dev repo and its
sub-modules, but I'd want a straightforward way to automate it so that I
can confidently be sure that my n.m work-tree contains everything that
matters in n.m, rather than only the parts of it I happen to have worked
on.

> FWIW, I used it once, when I did the first clone, to do exactly that
> kind of stuff. I never need it afterwards, and I rarely have to deal
> with git submodules (and I’m not sure if it’s supposed to be used
> afterwards), since I work in worktrees.

And it sounds like worktrees are great for your workflows.
So by all means let's document how to make good use of worktrees and,
where appropriate, add tooling to support that workflow.
Consider, however, that others have different work processes.

Last year I enacted lots of outstanding // ### Qt 6 comments, many of
which wanted deprecation and/or removal of methods, enum members and
other random cruft.  Of course, that meant I had to check for all
modules using those things.  For that, I needed a checkout that contains
everything so that I could grep for mentions of the thing I was
removing, to prepare the patches to other modules that would need to be
taken in before I could deprecate or remove them from core.

I also needed to do a build of everything, to try to catch any
compilation fall-out that would result from things my grep didn't catch.
(Things sometimes do stuff you can't anticipate, like synthesizing an
enum name using a macro, so that grep never finds the name being used.)
That mostly broke due to interdependency problems - I didn't know how to
ask the system to synchronise using dependencies.yaml files, thanks for
the recipe you gave today - but I guess I could fix it by taking a
leaf-most module, getting everything consistent with its dependency.yaml
and rebasing my qtbase removal change onto the selected qtbase revision,
to do a test build; so at least I now know how to do this.  (At the time
I just used make -k and checked for which of the failures appeared to
relate to my change.  It wasn't very reliable.)

For all of that, I needed all supported modules checked out somewhere,
and I don't want to have to keep track of mailing list announcements to
manual update the set of modules in my master repo.  So we need some
mechanism for automating checkout of "everything interesting" with some
fairly sensible mechanism for identifying which things are interesting -
which is going to vary between developers and, for any given developer,
between work trees.

So, before you throw out the whole supermodule, pause to answer how
we're going to do the things that we currently can do, that some of us
need, at least sometimes.

On a related note, I agree that all the provisioning stuff for Coin
belongs in a separate module: however, check with the Coin team for how
to make that work in practice, since it's been suggested before and they
had Reasons why it wasn't practical.

Eddy.

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

Re: [Development] Qt6 repo

[Volker Hilsheimer]

> On 14 Jan 2021, at 10:49, Benjamin TERRIER  wrote:
> On Thu, 14 Jan 2021 at 08:21, Nibedit Dey  wrote:
> Thank you everyone for the suggestions.
> I posted in the development group as there was less participation on the 
> topic in the interest group.
> Below are my suggestions:
>   • Create a clean qt6 supermodule for better maintainability. It's still 
> not too late.
>   • If the qt5 supermodule is renamed, then it will still have many qt5 
> branches. This may create confusion while looking for specific branches.
>   • The use of a script is a good idea, but it needs to be mentioned in 
> the README document. Else new Qt developer or contributors may face 
> difficulties while building from source.
> 
> Actually, I agree with Thiago and think that scripts to handle the branches 
> is a bad idea and that the current perl script should be gone.
> All is required for new Qt developers is:
> 1. A good branch naming scheme (this we have)
> 2. Rely on standard git submodule mechanisms
> 3. A clear documentation of the branch naming scheme and branching conventions
> 
> Adding a script only adds a black box and makes things confused. What is the 
> script doing? Is it doing special stuff ? Can I use a git submodule command 
> or will it break the magic the script did and I will have to rebuild 
> everything?
> If the goal is to ease the entry of new developers, the use of industry 
> standard tools is to be favored against the use of helper scripts.
> 
> Also I can see the point of renaming the 'qt5' repo to 'qt' since it contains 
> Qt 6 and Qt 5, but I cannot see the point of splitting the repo in 2 ('qt5' 
> and 'qt6').

If we don’t have any script, then people need to do the gerrit plumbing 
themselves. That’s not exactly lowering the entry level threshold, I think. I 
agree, we should not require scripts beyond that; fetching and managing the 
code should be trivial using standard git commands.

Here’s the specific problem i have with git submodules and worktrees:

$ cd ~/qt
$ git clone git://code.qt.io/qt/qt5.git
$ cd qt5
$ ./init-repository blah
$ git submodule foreach ‘git worktree add ~/qt/5.15/$name 5.15'
$ git submodule foreach ‘git worktree add ~/qt/6.0/$name 6.0’
$ git submodule foreach ‘git worktree add ~/qt/dev/$name dev’

Now I have a lovely set of worktrees, I can work on 5.15 by cd’ing into 
~/qt/5.15, and on dev by cd’ing into 6.0. I can

$ cd ~/qt/5.15/qtbase
$ git cherry-pick -x $commitsh_in_dev

and it works.

But: ~/qt/dev is empty; ~/qt/5.15 is empty. No toplevel build system (see 
earlier reply; in Qt 6 I find it really valuable), and no git submodules (which 
I don’t care about because I never use them; I just fetch and update for each 
worktree when I need to). I can shoehorn them in there, but it’s messy. Maybe 
someone has a better idea how that can be done?

From what I see, what I’d want is for the toplevel build system files to live 
in a separate repository. Then I can just add another worktree for that as 
well, and ignore that we are using git submodules. If I run into issues because 
changes between modules break things, then I can check out a consistent set 
based on the dependencies.yaml data (see earlier email). Those who want to use 
git submodules may do so.


Volker


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

Re: [Development] Qt6 repo

[Volker Hilsheimer]

> On 13 Jan 2021, at 22:58, André Pönitz  wrote:
> 
> On Wed, Jan 13, 2021 at 12:48:45PM -0800, Thiago Macieira wrote:
>> On Wednesday, 13 January 2021 10:17:02 PST André Pönitz wrote:
>>> I have a product that depends on qtbase, qtdeclarative and qttool, and
>>> qtdeclarative and qttools refer to different and incompatible versions
>>> of qtbase in their respective dependency.yaml files.
>>> 
>>> How do I build Qt?
>> 
>> There's no such thing.
> 
> You are telling me my day job doesn't exist?
> 
>> Any *product* is built with released versions of Qt, which means you
>> must have exactly the same releases of each module. No other
>> combination is supported.
> 
> I am not asking for *support*. I am asking how to find a recent working
> combination of Qt modules that I need for porting some code base to
> Qt 6. Don't tell me to use 6.0 nor to wait for some 6.x.

Our CI system should prevent that a change to a dependency.yaml file merges 
that results in multiple dependencies to several conflicting versions of any 
upstream library.

If a change to qttools/dependencies.yaml file adds a dependency to 
qtdeclarative:A and qtbase:B, but qtdeclarative:A depends on qtbase:A, then 
your change won’t merge (Coin will fail during provisioning).

Of course, as we develop on Qt we frequently have local worktrees that point to 
arbitrary revisions of each submodules, which then also might mean that you 
have dependency.yaml files pointing to “whatever”. That’s a choice. You can 
have the same thing with git submodules (checkout random sha in any submodule).


>> For people developing Qt, once you've checked the Git repositories out, it 
>> doesn't matter whether there's a .gitmodules or not to build.
> 
> Lacking a monolothic repo the superrepo is currently pretty much the only
> safe way to find a working combination of reasonably recent states of
> Qt modules. Sure, one can try HEAD of each module first, and it works
> sometimes. In a few more cases commenting out a few unneeded bits helps
> to make it work, but after the third attempt one wants a safe fall back.
> So far the superrepo delivers that.


So does the chain of dependencies.yaml files. If the above Coin process works, 
it results in a consistent set of dependencies. The closer you are to qtbase, 
the closer to HEAD your qtbase will probably be. If you want to work on a 
module far down the dependency tree, your qtbase might be older because not all 
dependencies have been updated.

git submodules only updates if everything works. That’s not useful if you 
primarily work on qtdeclarative, so only depend on qtbase (and yes, we want 
people working on qtdeclarative to test their changes against e.g. 
qtquickcontrols2 as well; but I hope you get my point).


> I am not a big fan of git submodules, nor does the effort spent on failed
> integration attempts look appealing. But effectively the central
> integration is the work that otherwise all users who need to keep up with
> the bleeding edge had to do by themselves.


Our CI system automatically updates the dependencies.yaml file gradually. If a 
change to qtbase merges, then soon after we will test qtdeclarative against 
that latest qtbase, and if things pass, the dependencies.yaml file in 
qtdeclarative will be changed to point to the new qtbase. This then triggers an 
update of the dependencies.yaml file in other modules.

If you base your checkout on a module at the very end of the dependency chain 
(qtdoc, I suppose), then you will get a stable, consistent set of all modules 
identical to what .gitmodules has.


>> For example, I always use the latest of the branch in question for
>> every module, regardless of what's stored in the super module.
> 
> How much do you depend on modules outside qtbase? With qtbase only you
> practically live in a world of a monolithic repo. Working HEAD is
> expected there.
> 
> 
> 
> In any case, the point was that "building according to dependency.yaml"
> doesn't give a "build". Different leave modules will have different
> dependencies on qtbase, which cannot be used at the same time.

See above, I hope this clarifies.

FWIW, try the following in your qt5.git clone repository

$ git submodule foreach 'git checkout origin/dev || true’ # go to the bleeding 
edge, no matter what .gitmodules says
$ cmake -DSYNC_TO_MODULE="qtdoc" -DSYNC_TO_BRANCH="6.0.0" -P 
cmake/QtSynchronizeRepo.cmake 

This will result in a local checkout of all submodules that qtdoc depends on, 
as per the 6.0.0 release:

Checking 'qtdoc' out to revision '6.0.0'
Checking 'qtquickcontrols2' out to revision 
'9a19ec26f45e7382431f52136f03887cfaa04b66'
Checking 'qttools' out to revision '3fd594493c3ba31639a7515b901554456a90b4c7'
Checking 'qtbase' out to revision 'fc9cda5f08ac848e88f63dd4a07c08b2fbc6bf17'
Checking 'qtdeclarative' out to revision 
'fa87052d56526e1529e694fb1c69c69eec38f2fd'
Checking 'qtsvg' out to revision '608054063bf58c555a1871e0a4df9c329c3b6885'

(checking where you are in each submodule 

Re: [Development] Qt6 repo

[Volker Hilsheimer]

> On 13 Jan 2021, at 17:28, Thiago Macieira  wrote:
> 
> On Wednesday, 13 January 2021 05:37:21 PST Volker Hilsheimer wrote:
>> * stop using git submodules
>> 
>> Using them serves no real purposes anymore. We anyway have our own scripting
>> in form of init-repository to avoid that people have to deal with that
>> stuff.
> 
> Please don't. In fact, I recommend the opposite: delete the Perl script and 
> use submodules properly.

The init-repository script does some extra work that is supposed to give people 
a leg up though, such as setting up commit hooks and remotes in all submodules.

FWIW, I used it once, when I did the first clone, to do exactly that kind of 
stuff. I never need it afterwards, and I rarely have to deal with git 
submodules (and I’m not sure if it’s supposed to be used afterwards), since I 
work in worktrees.

So, I think we can kill both the init-repostory script and .gitmodules as a way 
to get Qt; but some sort of script that sets other git things up locally might 
be the price we have to pay by using a repository service that people typically 
are not familiar with.


> I do use "git pull --recurse-submodules", "git submodule update", "git 
> submodule foreach", etc. often.
> 
>> The super-module, if we want to have it at all, can then be just the single
>> .gitmodules file. It might be relevant for the release team, and for those
>> of us who prefer to work with git submodules for… reasons. Ok, so I’m not a
>> fan of git submodules. Either way, it avoids the mixing “real code” (like
>> build system and coin configs) and submodule updates in the same
>> repository, which has historically caused an unfortunate entanglement of
>> unrelated things.
> 
> That works for me.
> 
> The primary and official way to build Qt is each submodule individually, with 
> "make install" in sequence. The merged content in a single build is secondary 
> and a convenience anyway.
> 
> PS: do uninstalled builds even work with CMake? That was a (mis)feature of 
> tmake and qmake…


Well, IF the canonical way of building Qt is to clone each submodule 
individually, then anything we provide as convenience to work with toplevel 
builds is just sugar on top anyway, and as long as it doesn’t get in the way 
it’s no problem.

But, our wiki [1] documents that building Qt from git involves cloning of 
qt5.git, running init-repository, and then a top-level build.

[1] https://wiki.qt.io/Building_Qt_5_from_Git

And while I don’t use top-level builds in Qt 5, in Qt 6 with cmake and ninja I 
find them incredibly convenient. Being able to run

$ ninja tst_class_I_fixed_check

and ninja rebuilding everything that needs to be rebuilt across all modules 
before running the test is a huge timesaver.

Volker

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

Re: [Development] Qt6 repo

[Benjamin TERRIER]

On Thu, 14 Jan 2021 at 08:21, Nibedit Dey  wrote:

> Thank you everyone for the suggestions.
> I posted in the development group as there was less participation on the
> topic in the interest group.
> Below are my suggestions:
>
>- Create a clean qt6 supermodule for better maintainability. It's
>still not too late.
>- If the qt5 supermodule is renamed, then it will still have many qt5
>branches. This may create confusion while looking for specific branches.
>- The use of a script is a good idea, but it needs to be mentioned in
>the README document. Else new Qt developer or contributors may face
>difficulties while building from source.
>
>
Actually, I agree with Thiago and think that scripts to handle the branches
is a bad idea and that the current perl script should be gone.
All is required for new Qt developers is:
1. A good branch naming scheme (this we have)
2. Rely on standard git submodule mechanisms
3. A clear documentation of the branch naming scheme and branching
conventions

Adding a script only adds a black box and makes things confused. What is
the script doing? Is it doing special stuff ? Can I use a git submodule
command or will it break the magic the script did and I will have to
rebuild everything?
If the goal is to ease the entry of new developers, the use of industry
standard tools is to be favored against the use of helper scripts.

Also I can see the point of renaming the 'qt5' repo to 'qt' since it
contains Qt 6 and Qt 5, but I cannot see the point of splitting the repo in
2 ('qt5' and 'qt6').


My 2 cents

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

Re: [Development] Qt6 repo

[Christian Kandeler]

On 1/13/21 11:46 PM, Thiago Macieira wrote:
Like I said above, the latest tip of the branch for every single 
module. This

recipe has worked for me for 10 years.


I don't believe you.


Christian

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

Re: [Development] Qt6 repo

[Nibedit Dey]

Thank you everyone for the suggestions.
I posted in the development group as there was less participation on the
topic in the interest group.
Below are my suggestions:

   - Create a clean qt6 supermodule for better maintainability. It's still
   not too late.
   - If the qt5 supermodule is renamed, then it will still have many qt5
   branches. This may create confusion while looking for specific branches.
   - The use of a script is a good idea, but it needs to be mentioned in
   the README document. Else new Qt developer or contributors may face
   difficulties while building from source.

Any thoughts?

Best Regards,
Nibedit

On Wed, Jan 13, 2021 at 4:06 PM Nibedit Dey  wrote:

> Hello Everyone,
>
> Is there any plan to move the qt6 source code to a different repo (qt6)?
> Currently, the branch lies inside the qt5 repo.
> Is there going to be a Qt6 super module in near future?
>
> Thanks & Regards,
> Nibedit
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt6 repo

[Thiago Macieira]

On Wednesday, 13 January 2021 13:58:42 PST André Pönitz wrote:
> > Any *product* is built with released versions of Qt, which means you
> > must have exactly the same releases of each module. No other
> > combination is supported.
> 
> I am not asking for *support*. I am asking how to find a recent working
> combination of Qt modules that I need for porting some code base to
> Qt 6. Don't tell me to use 6.0 nor to wait for some 6.x.

If you're a developer of Qt (which you are), then the latest dev branch of 
every module or the latest 6.0 branch of every module works. If there are 
issues, you need to fix them and contribute.

If you're not a developer of Qt, then use a release.

> > For people developing Qt, once you've checked the Git repositories out, it
> > doesn't matter whether there's a .gitmodules or not to build.
> 
> Lacking a monolothic repo the superrepo is currently pretty much the only
> safe way to find a working combination of reasonably recent states of
> Qt modules. Sure, one can try HEAD of each module first, and it works
> sometimes. In a few more cases commenting out a few unneeded bits helps
> to make it work, but after the third attempt one wants a safe fall back.
> So far the superrepo delivers that.

Like I said above, the latest tip of the branch for every single module. This 
recipe has worked for me for 10 years.

> > For example, I always use the latest of the branch in question for
> > every module, regardless of what's stored in the super module.
> 
> How much do you depend on modules outside qtbase? With qtbase only you
> practically live in a world of a monolithic repo. Working HEAD is
> expected there.

For my direct work, only qtbase.

For running Qt Creator, well, almost all of them.

> In any case, the point was that "building according to dependency.yaml"
> doesn't give a "build". Different leave modules will have different
> dependencies on qtbase, which cannot be used at the same time.

I didn't know that.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

Re: [Development] Qt6 repo

[André Pönitz]

On Wed, Jan 13, 2021 at 12:48:45PM -0800, Thiago Macieira wrote:
> On Wednesday, 13 January 2021 10:17:02 PST André Pönitz wrote:
> > I have a product that depends on qtbase, qtdeclarative and qttool, and
> > qtdeclarative and qttools refer to different and incompatible versions
> > of qtbase in their respective dependency.yaml files.
> > 
> > How do I build Qt?
> 
> There's no such thing.

You are telling me my day job doesn't exist?
 
> Any *product* is built with released versions of Qt, which means you
> must have exactly the same releases of each module. No other
> combination is supported.

I am not asking for *support*. I am asking how to find a recent working
combination of Qt modules that I need for porting some code base to
Qt 6. Don't tell me to use 6.0 nor to wait for some 6.x.

> For people developing Qt, once you've checked the Git repositories out, it 
> doesn't matter whether there's a .gitmodules or not to build.

Lacking a monolothic repo the superrepo is currently pretty much the only
safe way to find a working combination of reasonably recent states of
Qt modules. Sure, one can try HEAD of each module first, and it works
sometimes. In a few more cases commenting out a few unneeded bits helps
to make it work, but after the third attempt one wants a safe fall back.
So far the superrepo delivers that.

I am not a big fan of git submodules, nor does the effort spent on failed
integration attempts look appealing. But effectively the central
integration is the work that otherwise all users who need to keep up with
the bleeding edge had to do by themselves.

> For example, I always use the latest of the branch in question for
> every module, regardless of what's stored in the super module.

How much do you depend on modules outside qtbase? With qtbase only you
practically live in a world of a monolithic repo. Working HEAD is
expected there.



In any case, the point was that "building according to dependency.yaml"
doesn't give a "build". Different leave modules will have different
dependencies on qtbase, which cannot be used at the same time.

Andre'

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

Re: [Development] Qt6 repo

[Thiago Macieira]

On Wednesday, 13 January 2021 10:17:02 PST André Pönitz wrote:
> I have a product that depends on qtbase, qtdeclarative and qttool, and
> qtdeclarative and qttools refer to different and incompatible versions
> of qtbase in their respective dependency.yaml files.
> 
> How do I build Qt?

There's no such thing.

Any *product* is built with released versions of Qt, which means you must have 
exactly the same releases of each module. No other combination is supported.

For people developing Qt, once you've checked the Git repositories out, it 
doesn't matter whether there's a .gitmodules or not to build. For example, I 
always use the latest of the branch in question for every module, regardless 
of what's stored in the super module.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

Re: [Development] Qt6 repo

[André Pönitz]

On Wed, Jan 13, 2021 at 01:37:21PM +, Volker Hilsheimer wrote:
> [...]
> The workflow with such a setup would not be fundamentally different
> from today. You clone one thing (build system repo instead of
> qt5.git), you run a script and tell the script what you want to work
> on to get all the things you need. You build Qt more or less as
> before; the configure script lives in the build system repo rather
> than in some Qt super module clone. The file system structure will be
> a bit different.
> 
> 
> Advantage:
> 
> * no (inconsistently) duplicate information in .gitmodules vs
> dependency.yaml files

I have a product that depends on qtbase, qtdeclarative and qttool, and
qtdeclarative and qttools refer to different and incompatible versions
of qtbase in their respective dependency.yaml files.

How do I build Qt?

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

Re: [Development] Qt6 repo

[Thiago Macieira]

On Wednesday, 13 January 2021 05:37:21 PST Volker Hilsheimer wrote:
> * stop using git submodules
> 
> Using them serves no real purposes anymore. We anyway have our own scripting
> in form of init-repository to avoid that people have to deal with that
> stuff.

Please don't. In fact, I recommend the opposite: delete the Perl script and 
use submodules properly.

I do use "git pull --recurse-submodules", "git submodule update", "git 
submodule foreach", etc. often.
 
> The super-module, if we want to have it at all, can then be just the single
> .gitmodules file. It might be relevant for the release team, and for those
> of us who prefer to work with git submodules for… reasons. Ok, so I’m not a
> fan of git submodules. Either way, it avoids the mixing “real code” (like
> build system and coin configs) and submodule updates in the same
> repository, which has historically caused an unfortunate entanglement of
> unrelated things.

That works for me.

The primary and official way to build Qt is each submodule individually, with 
"make install" in sequence. The merged content in a single build is secondary 
and a convenience anyway.
 
PS: do uninstalled builds even work with CMake? That was a (mis)feature of 
tmake and qmake...

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

Re: [Development] Qt6 repo

[Thiago Macieira]

On Wednesday, 13 January 2021 04:18:53 PST Edward Welbourne wrote:
> ah, I think I see the source of the confusion.  IIUC, Qt 4 was a
> monorepo, that contained everything that's now in sub-modules; so the
> transition to Qt 5 was also the modularisation moment, calling for a new
> repo

Actually, what happened was that we were doing the modularisation of Qt 4 and 
we needed a repo name. At that point marketing suggested "qt5" and we ran with 
it. There was no reason the first modularised version needed to be 5.0 (it 
could have been 4.9), but it made complete sense to do the two things at the 
same time, because of the major build system rework.

And yes, someone at the time wondered what we'd do when 6.0 came along.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

Re: [Development] Qt6 repo

[Volker Hilsheimer]

> On 13 Jan 2021, at 15:22, Edward Welbourne  wrote:
> 
> Volker Hilsheimer (13 January 2021 14:37) wrote:
>> Let me make a more radical proposal:
>> 
>> The information about which modules depend on which others modules
>> lives in each module’s dependency.yaml file. This information includes
>> the sha1 of the modules it has last been successfully tested against.
>> 
>> This information is (inconsistently) duplicated in .gitmodules. So
>> proposal:
>> 
>> * stop using git submodules
>> 
>> Using them serves no real purposes anymore. We anyway have our own
>> scripting in form of init-repository to avoid that people have to deal
>> with that stuff.
> 
> Little detail: init-repository relies on the .gitmodules file and uses
> git submodule.  So eliminating git submodule in favour of a script that
> depends on it isn't an option.

The point I’m apparently failing to make is: we already have a script today 
that helps people check things out.

So, we could just as well have a script that uses the information in 
dependencies.yaml instead.


> In particular, qt5/.gitmodules contains information about module status,
> whether each is essential, deprecated, in preview, an addon or to be
> ignored.  My scripts to generate the api change reviews use this
> information to identify which modules are candidates for such a review.
> So it's not just init-repository (which does also use status info).
> 
> Not that this argues against more flexible tooling that relegates the
> super-module-based structure to the background, but we do still need the
> information presently contained in .gitmodules, although perhaps it's
> time to eliminate its dependency information in favour of the YAML
> config files.
> 
> We could, of course, move the information presently in .gitmodules into
> some other file within each module (possibly unifying this with what's
> presently in sync.profile and dependencies.yaml), if you're OK with
> rewriting init-repository (ideally in python3) as part of your plan.

Yes, that meta-data can live anywhere, using .gitmodules is of course 
convenient as long as we use git submodules, and as I said, for release and 
packaging purposes (which API review falls under in my mind), having a 
super-repo might make sense.

For working on Qt, the only information we need is “which modules need to be 
cloned so that it’s possible to build module X from source”. That information 
is available, once we have module X cloned, as we can walk the 
dependencies.yaml data to find out what else is needed. Configure could in 
principle do that, it already checks whether dependencies are missing.

Volker

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

Re: [Development] Qt6 repo

[Tor Arne Vestbø]

Cheers,
Tor Arne

On 13 Jan 2021, at 14:37, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:

On 13 Jan 2021, at 14:17, Dominik Holland 
mailto:dominik.holl...@qt.io>> wrote:

Am 1/13/21 um 1:19 PM schrieb Allan Sandfeld Jensen:

On Mittwoch, 13. Januar 2021 13:07:00 CET NIkolai Marchenko wrote:
that's ... kinda what you're supposed to avoid... at least as far as I
understand the convo earlier. so that two major versions aren't pushed to
the same repo confusing people.

I don't see any problems with that. It is how all the other modules are used.

'Allan

Why not create a qt6 super repo, which host qt6 for now and just create
a alias qt.git which always points to the latest qt release.

Later this could point to a qt7 release. I guess we don't want to go
back to a monorepo, but we never know, so this would atleast help to not
block this road...

Dominik


Let me make a more radical proposal:

+1 on all of the proposed.

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

Re: [Development] Qt6 repo

[Edward Welbourne]

Volker Hilsheimer (13 January 2021 14:37) wrote:
> Let me make a more radical proposal:
>
> The information about which modules depend on which others modules
> lives in each module’s dependency.yaml file. This information includes
> the sha1 of the modules it has last been successfully tested against.
>
> This information is (inconsistently) duplicated in .gitmodules. So
> proposal:
>
> * stop using git submodules
>
> Using them serves no real purposes anymore. We anyway have our own
> scripting in form of init-repository to avoid that people have to deal
> with that stuff.

Little detail: init-repository relies on the .gitmodules file and uses
git submodule.  So eliminating git submodule in favour of a script that
depends on it isn't an option.

In particular, qt5/.gitmodules contains information about module status,
whether each is essential, deprecated, in preview, an addon or to be
ignored.  My scripts to generate the api change reviews use this
information to identify which modules are candidates for such a review.
So it's not just init-repository (which does also use status info).

Not that this argues against more flexible tooling that relegates the
super-module-based structure to the background, but we do still need the
information presently contained in .gitmodules, although perhaps it's
time to eliminate its dependency information in favour of the YAML
config files.

We could, of course, move the information presently in .gitmodules into
some other file within each module (possibly unifying this with what's
presently in sync.profile and dependencies.yaml), if you're OK with
rewriting init-repository (ideally in python3) as part of your plan.

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

Re: [Development] Qt6 repo

[Volker Hilsheimer]

> On 13 Jan 2021, at 14:17, Dominik Holland  wrote:
> 
> Am 1/13/21 um 1:19 PM schrieb Allan Sandfeld Jensen:
> 
>> On Mittwoch, 13. Januar 2021 13:07:00 CET NIkolai Marchenko wrote:
>>> that's ... kinda what you're supposed to avoid... at least as far as I
>>> understand the convo earlier. so that two major versions aren't pushed to
>>> the same repo confusing people.
>>> 
>> I don't see any problems with that. It is how all the other modules are used.
>> 
>> 'Allan
>> 
> Why not create a qt6 super repo, which host qt6 for now and just create
> a alias qt.git which always points to the latest qt release.
> 
> Later this could point to a qt7 release. I guess we don't want to go
> back to a monorepo, but we never know, so this would atleast help to not
> block this road...
> 
> Dominik


Let me make a more radical proposal:

The information about which modules depend on which others modules lives in 
each module’s dependency.yaml file. This information includes the sha1 of the 
modules it has last been successfully tested against.

This information is (inconsistently) duplicated in .gitmodules. So proposal:

* stop using git submodules

Using them serves no real purposes anymore. We anyway have our own scripting in 
form of init-repository to avoid that people have to deal with that stuff.

Note that the cmake top level build system is already operating on the data in 
dependency.yaml to figure out the order in which things need to get configured. 
It doesn’t care about .gitmodules.

That cmake tooling also knows how to fetch the dependencies needed (see 
https://code.qt.io/cgit/qt/qt5.git/tree/cmake/QtTopLevelHelpers.cmake#n155). 
This can in theory (and in practice; that’s what I’m using) replace the 
init-repository script to some degree (commit hooks and other gerrit 
shenanigans require some extra love, I suppose).


The main problem I see with us using git submodules is that it makes it a royal 
mess to work with git worktrees. I have separate worktrees for all modules (ie 

$ git worktree add ~/qt/dev/qtbase dev
$ git worktree add ~/qt/6.0/qtbase 6.0
$ git worktree add ~/qt/515/qtbase 5.15

repeat for most other modules), which makes it easy to work on several 
branches, test changes in several branches, and cherry-pick changes across. I 
can’t use (or at least there is no point in using) git submodules.



* move the top level build system files into a dedicated repo

That dedicated repo has branches for different Qt versions, nothing special 
about it. We shall perhaps not call it “Qt Build System” :P

The super-module, if we want to have it at all, can then be just the single 
.gitmodules file. It might be relevant for the release team, and for those of 
us who prefer to work with git submodules for… reasons. Ok, so I’m not a fan of 
git submodules. Either way, it avoids the mixing “real code” (like build system 
and coin configs) and submodule updates in the same repository, which has 
historically caused an unfortunate entanglement of unrelated things.


The workflow with such a setup would not be fundamentally different from today. 
You clone one thing (build system repo instead of qt5.git), you run a script 
and tell the script what you want to work on to get all the things you need. 
You build Qt more or less as before; the configure script lives in the build 
system repo rather than in some Qt super module clone. The file system 
structure will be a bit different.


Advantage:

* no (inconsistently) duplicate information in .gitmodules vs dependency.yaml 
files
* cloning and building are based on the same information (dependency.yaml files)
* easier to work with multiple worktrees
* any Qt add-on module (which can live on any repository server) can be treated 
the exact same way as the default modules. Put a dependency.yaml file into your 
add-on repo, and you’re done


Fringe benefits for git submodule dislikers:
* git status from git submodules being changed won’t make things light up in 
IDEs
* no need to deal with git submodules at all


Cheers,
Volker


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

Re: [Development] Qt6 repo

[Dominik Holland]

Am 1/13/21 um 1:19 PM schrieb Allan Sandfeld Jensen:

> On Mittwoch, 13. Januar 2021 13:07:00 CET NIkolai Marchenko wrote:
>> that's ... kinda what you're supposed to avoid... at least as far as I
>> understand the convo earlier. so that two major versions aren't pushed to
>> the same repo confusing people.
>>
> I don't see any problems with that. It is how all the other modules are used.
>
> 'Allan
>
Why not create a qt6 super repo, which host qt6 for now and just create
a alias qt.git which always points to the latest qt release.

Later this could point to a qt7 release. I guess we don't want to go
back to a monorepo, but we never know, so this would atleast help to not
block this road...

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

Re: [Development] Qt6 repo

[Allan Sandfeld Jensen]

On Mittwoch, 13. Januar 2021 13:07:00 CET NIkolai Marchenko wrote:
> that's ... kinda what you're supposed to avoid... at least as far as I
> understand the convo earlier. so that two major versions aren't pushed to
> the same repo confusing people.
> 
I don't see any problems with that. It is how all the other modules are used.

'Allan


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

Re: [Development] Qt6 repo

[Edward Welbourne]

NIkolai Marchenko (13 January 2021 13:07)
> that's ... kinda what you're supposed to avoid... at least as far as I
> understand the convo earlier. so that two major versions aren't pushed
> to the same repo confusing people.

ah, I think I see the source of the confusion.  IIUC, Qt 4 was a
monorepo, that contained everything that's now in sub-modules; so the
transition to Qt 5 was also the modularisation moment, calling for a new
repo.  There's no problem with having several branches, even for major
versions, in the same repo.  The only issue with Qt 6 living in the
qt5.git repo is that the repo name misguidedly suggests only Qt5 lives
there, when actually nothing prevents all later versions, major and
minor, going into it.  So renaming it qt.git and having all future major
versions live there, along with the 5 and 6 it already contains, would
work just fine.

Compare qtbase.git, which contains Qt 5 and Qt 6 branches,

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

Re: [Development] Qt6 repo

[Edward Welbourne]

On Mittwoch, 13. Januar 2021 12:31:50 CET Eric Lemanisser wrote:
 that's the obvious choice, if it was not already used by qt4.

On 13 Jan 2021, at 12:38, Allan Sandfeld Jensen 
mailto:k...@carewolf.com>> wrote:
>>> Then rename the qt4 repo, it is not actively maintained anymore and
>>> only stored for history. We couldn't do that when creating qt5 as it
>>> was still actively maintained and would break a lot of checkouts,
>>> but we could do it now.

On Wed, Jan 13, 2021 at 2:59 PM Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:
>> I agree, that seems like the easiest and most future-proof solution.

Nikolai Marchenko (13 January 2021 13:01)
> except when qt7 comes you'll be stuck with versionless qt6 branch that
> you wouldn't be able to move to qt7 because of aforementioned
> dependency breakages.

I'm confused - what's the problem ?

After we rename the old qt.git to qt4.git and the present qt5.git to
qt.git, the latter can have separate branches for 5, 6, 7, ... for ever
after, until we invent a new repository structure.  What would be the
problem with doing that ?

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

Re: [Development] Qt6 repo

[NIkolai Marchenko]

that's ... kinda what you're supposed to avoid... at least as far as I
understand the convo earlier. so that two major versions aren't pushed to
the same repo confusing people.

On Wed, Jan 13, 2021 at 3:04 PM Allan Sandfeld Jensen 
wrote:

> On Mittwoch, 13. Januar 2021 13:01:30 CET NIkolai Marchenko wrote:
> > except when qt7 comes you'll be stuck with versionless qt6 branch that
> you
> > wouldn't be able to move to qt7 because of aforementioned dependency
> > breakages.
> >
> Why not? It would just be a new branch in the same repo
>
> Best regards
> Allan
>
>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt6 repo

[Allan Sandfeld Jensen]

On Mittwoch, 13. Januar 2021 13:01:30 CET NIkolai Marchenko wrote:
> except when qt7 comes you'll be stuck with versionless qt6 branch that you
> wouldn't be able to move to qt7 because of aforementioned dependency
> breakages.
> 
Why not? It would just be a new branch in the same repo

Best regards
Allan


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

Re: [Development] Qt6 repo

[NIkolai Marchenko]

except when qt7 comes you'll be stuck with versionless qt6 branch that you
wouldn't be able to move to qt7 because of aforementioned dependency
breakages.

On Wed, Jan 13, 2021 at 2:59 PM Tor Arne Vestbø 
wrote:

> >
> > On 13 Jan 2021, at 12:38, Allan Sandfeld Jensen 
> wrote:
> >
> > On Mittwoch, 13. Januar 2021 12:31:50 CET Eric Lemanisser wrote:
> >> that's the obvious choice, if it was not already used by qt4.
> >>
> > Then rename the qt4 repo, it is not actively maintained anymore and only
> > stored for history. We couldn't do that when creating qt5 as it was
> still
> > actively maintained and would break a lot of checkouts, but we could do
> it
> > now.
>
> I agree, that seems like the easiest and most future-proof solution.
>
> Cheers,
> Tor Arne
>
>
> ___
> 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] Qt6 repo

[Tor Arne Vestbø]

> 
> On 13 Jan 2021, at 12:38, Allan Sandfeld Jensen  wrote:
> 
> On Mittwoch, 13. Januar 2021 12:31:50 CET Eric Lemanisser wrote:
>> that's the obvious choice, if it was not already used by qt4.
>> 
> Then rename the qt4 repo, it is not actively maintained anymore and only 
> stored for history. We couldn't do that when creating qt5 as it was still 
> actively maintained and would break a lot of checkouts, but we could do it 
> now.

I agree, that seems like the easiest and most future-proof solution.

Cheers,
Tor Arne


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

Re: [Development] Qt6 repo

[Allan Sandfeld Jensen]

On Mittwoch, 13. Januar 2021 12:31:50 CET Eric Lemanisser wrote:
> that's the obvious choice, if it was not already used by qt4.
> 
Then rename the qt4 repo, it is not actively maintained anymore and only 
stored for history. We couldn't do that when creating qt5 as it was still 
actively maintained and would break a lot of checkouts, but we could do it 
now.

Best regards
Allan


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

Re: [Development] Qt6 repo

[Eric Lemanisser]

that's the obvious choice, if it was not already used by qt4.

Eric


Le mer. 13 janv. 2021 à 12:27, Allan Sandfeld Jensen  a
écrit :

> On Mittwoch, 13. Januar 2021 11:36:14 CET Nibedit Dey wrote:
> > Hello Everyone,
> >
> > Is there any plan to move the qt6 source code to a different repo (qt6)?
> > Currently, the branch lies inside the qt5 repo.
> > Is there going to be a Qt6 super module in near future?
> >
> If it is going to be a general root name. I would suggest qt.git, so we
> don't
> need to rename again for qt 7.
>
> Allan
>
>
>
> ___
> 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] Qt6 repo

[Allan Sandfeld Jensen]

On Mittwoch, 13. Januar 2021 11:36:14 CET Nibedit Dey wrote:
> Hello Everyone,
> 
> Is there any plan to move the qt6 source code to a different repo (qt6)?
> Currently, the branch lies inside the qt5 repo.
> Is there going to be a Qt6 super module in near future?
> 
If it is going to be a general root name. I would suggest qt.git, so we don't 
need to rename again for qt 7.

Allan



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

Re: [Development] Qt6 repo

[Andy Nichols]

So let's have the discussion then. Qt is already ridiculously hard to build and 
contribute to for new-commers not already well acquainted with the arcane 
knowledge without additional silliness like this.  Qt 6 has been released, so 
it's a bit ridiculous at this point to still point contributors at the qt5.git 
super module to contribute to Qt 6.

qt = qt4
qt5 = qt5 and qt6 (depends on branch).

We could come up with a solution that avoids this.  Why not just have a new 
supermodule specifically for Qt6 or for even lower effort have an alias repo 
called qt6.  It's such a small thing in practice, but it causes unnecessary 
confusion for those not already in-the-know.

Regards,
Andy Nichols

-Original Message-
From: Development  On Behalf Of Alex Blasche
Sent: Wednesday, January 13, 2021 11:56 AM
To: Nibedit Dey ; development@qt-project.org
Subject: Re: [Development] Qt6 repo

> -Original Message-
> From: Development  On Behalf Of 
> Nibedit Dey Is there any plan to move the qt6 source code to a 
> different repo (qt6)?
> Currently, the branch lies inside the qt5 repo.
> Is there going to be a Qt6 super module in near future?

Thiago's reply from the interest mailing list still stands. There has not been 
any discussion or plan being made.

--
Alex
___
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] Qt6 repo

[Roland Winklmeier]

Alex Blasche  schrieb am Mi. 13. Jan. 2021 um
11:58:

> > -Original Message-
> > From: Development  On Behalf Of
> > Nibedit Dey
> > Is there any plan to move the qt6 source code to a different repo (qt6)?
> > Currently, the branch lies inside the qt5 repo.
> > Is there going to be a Qt6 super module in near future?
>
> Thiago's reply from the interest mailing list still stands. There has not
> been any discussion or plan being made.


Well, how about starting a discussion then? I guess that was the intention
of the originator.

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

Re: [Development] Qt6 repo

[Alex Blasche]

> -Original Message-
> From: Development  On Behalf Of
> Nibedit Dey
> Is there any plan to move the qt6 source code to a different repo (qt6)?
> Currently, the branch lies inside the qt5 repo.
> Is there going to be a Qt6 super module in near future?

Thiago's reply from the interest mailing list still stands. There has not been 
any discussion or plan being made.

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

[Development] Qt6 repo

[Nibedit Dey]

Hello Everyone,

Is there any plan to move the qt6 source code to a different repo (qt6)?
Currently, the branch lies inside the qt5 repo.
Is there going to be a Qt6 super module in near future?

Thanks & Regards,
Nibedit
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development