[Development] Coin news

[Jędrzej Nowacki]

On onsdag 26. oktober 2016 11.28.28 CEST Oswald Buddenhagen wrote:
> that's indeed better in the optimal case:
> 1. prepare downstream module and update upstream module
> 2. have them integrated into qt5. make sure that the upstream update
>    does not go in before the downstream adjustment (you can generally
>    assume an atomic integration).
> 3. clean up both modules
> 4. have them integrated into qt5. make sure the upstream cleanup does
>    not go in before the downstream cleanup.
The only problem is that you have to be sure to prepare downstream module 
right, because only one code path will be tested, but it is still ok. Btw. 
earlier by referring to a two steps process I meant that you need to 

> another good thing about this variant is that you can atomically fix
> issues introduced due to signal/slot overloading, which you'd otherwise
> have to do separately in advance, introducing yet another two-stage
> integration.
Yes.

> a downside is that the history is messier, because there are inherently
> at least two commits in every downstream module. and it may get even
> more messy if you notice later in the process that you need to adjust
> the downstreams further before the qt5 integration succeeds. that's
> because the downstream integrations are basically dummies and you don't
> notice that something went wrong until the qt5 integration which pulls
> in the upstream change.
I would not be worried about history too much, it just reflects the reality. I 
had idea to mitigate the late discovery problem by adding a 2nd job to CI that 
would do a fast qt5  incremental build check just on Linux. With proper setup 
(unionfs like partitions) and reduced load (that we've achieved) we could 
potentially run it for every patch set. 

Cheers,
  Jędrek