CI Requirements - Lessons Not Learnt?

Scarlett Clark scarlett.gately.clark at gmail.com
Wed Jan 11 14:23:50 GMT 2017


On Wed, Jan 11, 2017 at 4:40 AM, Jan Kundrát <jkt at kde.org> wrote:

> 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?
>

This seems like a good idea to me. I have always thought we should have
more than one distro image. I will even take the responsibility of
maintaining them.
Scarlett


>
> Cheers,
> Jan
>
> --
> Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20170111/a6011716/attachment.htm>


More information about the kde-core-devel mailing list