[Development] Suggestion for new CI: "early warning" for qt5.git

[Alan Alpert]

On Fri, 27 Jan 2012 23:07:07 ext Olivier Goffart wrote:
> On Friday 27 January 2012 09:09:46 Kent Hansen wrote:
> [...]
> 
> > If there is no quick fix, the last resort is to "pin" one or
> > more of the dependencies' to a particular SHA1 (e.g. from the qt5.git
> > submodule) in the sync.profile until the issue has been resolved, then
> > "unpin" it again later.
> 
> Why is that the "last resort"?
> This seems totally normal and was the whole point of modularisation:
> Differents modules can be developped at different speed.

It's the last resort because proper modularization isn't going to cause these 
sorts of problems. Proper modularization means that you aren't going to screw 
up dependent modules unless you make deliberately incompatible changes to your 
API, for which you normally will provide a smooth transition path (e.g. 
deprecate the old one and let them live side by side for a while). So these 
shouldn't happen, and your first step should be to fix your smooth transition 
path to be smooth enough for CI not to be blocked. Because CI blocking would 
mean that users of your module have just had their code broken by a module 
below. We don't like putting them in that situation.

That said, stuff exists like QtDeclarative reaching deep into the private 
headers of QtCore, and depending on details of the metatype system. So we're 
largely suffering because we have not been able to modularize properly.
 
> If not, modularisation was just a waste of time and a way to make
> development more difficult.

Arguably we have not successfully modularized if we still have such tight 
dependencies. But I'm optimistic enough to think it will settle down once 
5.0.0 is out and we're vaguely respecting compatibility again :) .

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks