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