CI Requirements - Lessons Not Learnt?

Jan Kundrát jkt at kde.org
Wed Jan 11 12:40:19 GMT 2017


On středa 11. ledna 2017 6:57:50 CET, Martin Gräßlin wrote:
> That doesn't work. Such inflexibility take away the advantage 
> of having a CI.

What base system(s) do you prefer to target as a developer, Martin?

A CI system can have different sets of base images for different projects 
(and different branches, etc). Something along these lines:

- KF5 might care a bit about slow-moving distributions such as RHEL7 (well, 
except for a requirement on Qt 5.6)

- Plasma LTS might want to target versions of faster-moving distros which 
were around at a time of their release. Say, Fedora 24? Ubuntu 16.04 LTS?

- The master branches of Plasma might want to get rid of the legacy 
workarounds. Can we use the latest Fedora with aggressive backports of 
rawhide packages upon request for this?

- Various applications within KDE might have completely different 
requiremens. Some "leaf" applications might want to target slow-moving 
distributions with their ancient Qt.

So this incomplete set of requirements probably translates to four base 
images. I'm using a RPM-centric terminology and picking these distros 
because of my professional background with these systems:

1) CentOS 7 with Qt 5.6 from EPEL and installed devtoolset
2) Ubuntu 16.04 LTS with a distro Qt (that is 5.5)
3) latest Fedora with Qt from git and an unspecified number of packages 
from rawhide
4) Debian Jessie with a system Qt 5.3

Each project in KDE can then choose whether they care about these 
individual base images (subject to the availability of dependencies, of 
course -- if KF5 don't care about Jessie and Qt 5.3, no project which uses 
any KF5 can possibly opt in to support that configuration for obvious 
reasons). By default, all projects get just 3) for the "latest and 
greatest" and for minimal wasted manpower.

With my (non-KDE) sysadmin hat on, I believe that the infrastructure should 
be provided as a service offering for developers. It is the developer's job 
to produce working code which is packageable. I don't think it's a 
developer's job to make a CI's sysadmin life uneventful, though. Perhaps 
the architecture outlined above can help achieve these goals with minimal 
manpower?

Cheers,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/




More information about the kde-core-devel mailing list