Everyone knows that recently KDE SIG became more and more present and
active. The goal is towards make KDE a good citzen on Fedora world.
On latest meeting, i put under scrutiny to have a continuous integration
process to keep up to date on recent releases.
The initial idea is keep a continuous build on fix branch commits, not a
daily yet, but this will be evaluated if this initial process proves a
So, Rex Dieter asked me to present the possible solutions, and open the
discussion here until a final decision is be made. I will not discuss the
resources needed now, because this will be defined depending
on the solution we decide. Please be constructive. So here we are of the
1 - Using rawhide directly - This will make us have less work on the
official releases since is already submitted on main Fedora database.
We will need a secondary machine to run a setup script on
jenkins ( or similar ).
What counts against this procedure is that packages will be available only
to rawhide users, limiting our test field ground.
We will rely on a semi-complex process on look on kde git tree, built the
tarballs, generate the packages and send to compilation on koji
2 - Using Copr kdesig directly - This will make us have less work similar
as previous option, same external machine to jenkins ( or similar ).
On the pro side of this solution, we can have all arches and fedora
releases, including epel 7, been tested and have packages available for
What counts against is that we will need more extra work to the moment that
we decide that the package x.y.z is good to consumption on the release
servers ( koji )
3 - Use KDE infrastructure and build our packages there. Before someone
raise the argument that KDE project doesn't look some place to do this,
recently we have the Noon project,
that is building basically a Debia/Ubuntu distro inside the project fully
accepted. So, there's no ground reasons to us request same thing if needed.
Under KDE infrastructure, we could use their jenkins CI and at same time we
would be glued on the KDE servers easing the git version pooling.
The downside on this is that the generated artifacts will not be in a
repository, so we still need a secondary machine to get the repository and
at same time decide where to go the results.
I personally think this is last resort, because will be too much work and
could end up in not be successful
4 - The Hybrid solution - We get Copr or Rawhide solutions and add KDE
Jenkins CI as the control machine. Using the command line capabilities of
both koji and copr, we can easily setup a big compile job
on some of this ones, controlled by the machine on KDE infra.
This is my particular choice using copr, even not been the most simple,
since we connect the both interested tech parts, KDE and Fedora, been KDE
ready on the jb setup, git control on KDE repo, and Copr
have all necessary Fedora parts to build the results.
What counts against it is the initially complicated setup on integrate both
techies, but i think is manageable.
So, let's open for discussions.
Regards, and Froeh Weihnachten :-)
Show replies by date