[Development] GitHub Pull requests

Thiago Macieira thiago.macieira at intel.com
Fri Mar 13 06:51:31 CET 2020


On Thursday, 12 March 2020 13:29:10 PDT Robert Löhning wrote:
> > Why would we do that?
> 
> Hi,
> 
> after having worked in a project in GitHub for a couple of months now
> and seeing their CI from the user perspective, this sounds feasible to me.
> 
> - changes are CI-tested individually, not as a random mixture of
> unrelated changes
> - changes are first tested using cheap computing time, there's no need
> to invest expensive developer's time first
> - the progress and results are comprehensible, you can look at the CI
> run just like you look at your local console window, in real time
> 
> Why would we not do that?

We would do that too if it didn't take over 2 hours for each change to be 
tested. It can be done, at a cost of more computing power: we can scale this 
up by testing changes in parallel, assuming optimistically that the previous 
change will successfully integrate. If it doesn't, then discard all pending 
tests and start over.

The problem is not will or want, it's cost.

> In addition, we wouldn't have to maintain the platform anymore.

That's an illusion. Someone has to maintain the CI, even if it's just small 
files you put in your repository. For TinyCBOR, which as its name says is 
tiny, it consumes me about half the time every year I can dedicate to the 
project just to update the .travis.yml file to deal with the environment 
changing. I also need two CIs so I can test on just three OSes.

For a complex set of needs like Qt's, you'l still need a dedicated person or 
multiple people. And this isn't free either, despite there being a lot of free 
CIs for open source projects: first, because it's meant to serve the 
commercial version too and second because the free computing power is likely 
to be insufficient for Qt's needs. We'll need to purchase additional time or 
do Bring Your Own VM or Bring Your Own Container so we can test on more 
configurations than the CI provides, which means sysadmins are needed to keep 
those configurations running.

If you meant "maintain the hardware and connectivity" when you said "maintain 
the platform", then yes, there would be improvement. Using the cloud and IaaS 
would alleviate the maintenance burden and possibly lower TQtC's cost. But it 
wouldn't eliminate: you still need a sysadmin to configure the cloud 
orchestration.

Please note this is not just wild guessing. I am looking into this very topic 
(GitHub repositories, CI, etc.) as part of my work inside Intel.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products





More information about the Development mailing list