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
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
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 th
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
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
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 t
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,
> 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
>>
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 Marchenk
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 agai
> 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
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 confusin
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
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
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 st
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 Marche
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 regard
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,
>
> 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. W
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 maintaine
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)?
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
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
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 su
> -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 maili
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
Devel
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 o
27 matches
Mail list logo
