[Development] Qt modules, API changes and Qt 6

[Frederik Gladhorn]

On tirsdag 29. januar 2019 11:07:55 CET Alex Blasche wrote:
> >From: Development <development-bounces at qt-project.org> on behalf of
> >Frederik Gladhorn <Frederik.Gladhorn at qt.io>
> 2 Heads: use the latest revision of each branch (the system we used to have
> in the past)
> 
> >3 Modules containing pinned dependency sha1s
> >
> >        Each module is completely self-contained, that means qt5 is not
> >
> >required as such (but may still exist as a collection of all modules, for
> >convenience and releases). In each module we have a list of dependencies
> >and their sha1.
> >
> >        Updates for a release (and also otherwise) must happen regularly
> >        (e.g.
> >
> >nightly), moving each module forward towards newer dependencies, this would
> >be implemented as bot which updates the above mentioned requirements file.
> I like this one. As you mentioned, we kind of had it already with
> sync.profiles.And really, if you implement this option you can almost
> implicitly run option 2 above too. In fact some modules might even want to
> do that if you permit SHA definition based on HEAD of some other
> repo/branch.
> 
>  There is one big question though. I vaguely recall one of the reasons for
> going to today's model was to limit the number of potential builds. This
> model could have 10 different modules/repos using different SHA's for all
> of its dependencies. Doesn't this increase the amount of different module
> builds which you have to store for later CI runs or build e.g. qtbase more
> often? Do we have the capacity/storage for it?

Yes, this is what we ended up with as well, module pinning seems like the way 
to go. It seems to solve a bunch of issues and we'd like to try implementing 
it (a few lines in how the CI resolves dependencies and writing the bot that 
bumps dependencies forward).

The capacity is something to look at, but considering how many failed qt5.git 
updates we have, I'm actually hoping that we get a better success rate with 
this model.

Other things to figure out are provisioning (how we prepare the VMs on which 
we build and test) and what the files specifying the dependencies should look 
like.

So option 3 is the favorite, but we need to clarify a few details.

Cheers,
Frederik


> 
> --
> Alex
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development