On Thu, Jan 12, 2017 at 3:23 AM, Scarlett Clark <scarlett.gately.cl...@gmail.com> wrote: > > > On Wed, Jan 11, 2017 at 4:40 AM, Jan Kundrát <j...@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/ > >