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

Re: [Development] access to codereview.qt-project.org

[Andrei Golubev]

Hi Evgeny,

I remember having some issues with git/gerrit process after messing with 
emails, etc. (still not sure what the issue was, to be honest).

As Alex mentions, it's better if you could attach an error message or something 
of the kind - right now it's not even clear whether it's git side or gerrit 
server-side issue.

My best suggestions:

  *   Make sure your other email is added to the Gerrit account + (if you use 
SSH to authenticate/push/etc.) check whether you have an SSH key for the email 
you want to use now
  *   Check git config's name/email strings for the repository, it might be old 
email or something and this is one of the issues. From what I remember, the 
commit's author and commit's pusher are taken from different places (not sure 
where in git this is recorded - hooks look OK at a glance), so it might be that 
you commit with correct credentials but push with an old email and this is 
rejected because the old email is no longer in the system
  *   Just try a clean pull of qt5.git or whatever you're using as a base repo, 
I have a feeling that Qt specific repo setup scripts affect the git push, so it 
might work (or not) if you start anew - you can check git push with some 
meaningless change like commit message update

--
Best Regards,
Andrei

From: Development  on behalf of Alex 
Blasche 
Sent: Wednesday, January 13, 2021 8:24 AM
To: development@qt-project.org ; Евгений Штанов 

Subject: Re: [Development] access to codereview.qt-project.org

HI Evgeny,

Did you follow all the steps outlined by https://wiki.qt.io/Setting_up_Gerrit ? 
Please double check.

It is hard to determine what your problem might be if you do not provide a 
description of your problem. I am sure there is some error report somewhere.

--
Alex


From: Development  on behalf of Евгений 
Штанов via Development 
Sent: Tuesday, 12 January 2021 22:28
To: development@qt-project.org
Subject: [Development] access to codereview.qt-project.org

Hello everyone.
This is my first appearance here.

André Hartmann 
recommended to write:
https://bugreports.qt.io/browse/QTBUG-85611?focusedCommentId=547986=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-547986

My problem is that I cannot do "git push gerrit HEAD:refs/for/dev" and even 
cannot edit or add patches to already opened commits on 
codereview.qt-project.org.
But I was able to do it earlier.
I removed one of my emails added during registration. My current email is 
shtanov_evge...@mail.ru
and I want to do commits signed with this email.

--
Best,
Evgeny Shtanov

___
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