On tirsdag 29. januar 2019 11:07:55 CET Alex Blasche wrote: > >From: Development <development-boun...@qt-project.org> on behalf of > >Frederik Gladhorn <frederik.gladh...@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@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development