CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Thu, Jan 12, 2017 at 3:23 AM, Scarlett Clark
<scarlett.gately.clark at gmail.com> wrote:
>
>
> 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.

Until our recent move towards Products / Tracks this hasn't even been
something we could even think about due to the nature of how
dependencies were resolved.
In theory, with a bit of manoeuvring it can theoretically be done. The
hard part will be any dependencies which traverse the Product boundary
more than once.

> Scarlett
>

Cheers,
Ben

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