Hello all

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 winning choice.

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 options:

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 many users.
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 :-)