Council Engineering update

Honza Horak hhorak at
Fri Jul 10 17:32:59 UTC 2015

On 07/10/2015 08:24 AM, Honza Horak wrote:
> * shortly summarize plans for upcoming Fedora releases (F23/F24) in
> their fields of interests and send it to working group ML or update in [2]

 From my PoV, these are ideas that I'd like to work on more for F23/F24. 
This is more an optimistic view, since I expect there won't be enough 
time or/and manpower to focus on all the things.

1) Playground repository (F23/F24)

Playground repository will allow to distinguish between random copr 
package and package that is built in copr, but is considered healthy. It 
is mainly meant to offer packages that cannot be part of standard 
Fedora, for example because of not following all the guidelines. A 
typical example of a package from playground might be software that 
bundles other projects.

Current status of Playground repository is that copr packages are signed 
(which was one of the requirements for playground), the copr GUI allows 
to tick copr to be included in the Playground, client plugin in dnf then 
allows to install the packages.

The missing piece in this project is finalizing the process (who will 
tick copr projects and what will be the guidelines to do it) and 
implementing at least some automated tests (rpmgrill seems like one 
thing worth pulling in).

Personally, what I'd like to see is a possibility to enable all the 
packages at once, in comparison (or in addition) to standard way how 
copr works -- every copr repository is enabled separatly. Technical 
details how to do this are still being discussed and implementation is 
not yet ready.

2) RPMGrill run for every build (F24)

RPMGrill ( is tool that 
reports mostly valid issues in RPMs just analyzing the packages 
statically. Results from this tool could be beneficial for packagers, so 
the idea is to run this tool for every build submitted to bodhi (by 
taskotron). The missing part here is basically a libtaskotron module 
that would connect taskotron and rpmgrill tool, while we need to handle 
the logs somehow.

The same would then be great even for copr builds:

3) Continuous Integration and functional tests in Fedora (F23/F24)

Taskotron serves as general launcher of various tasks and one of those 
tasks could also be tests of particular components (packages or group of 
packages) that cannot be run during build (traditional unit tests). 
Example of such tests might be checks of functionality of whole daemon, 
whether it works with systemd, SELinux and other programs, which is not 
possible to test during build.

Even if Taskotron misses features to run destructive tests for just 
particular packages, Fedora would still benefit from having such tests 
already. Those would be run by users or some other system initially. 
Crutial thing is that we need to have a place for those tests and at 
least some few guidelines or best practices how the tests would be 
called. The implementation itself would be up to author.

4) Software Collections in Fedora (F24)

This is a big topic that was already discussed a lot before and didn't 
end with success yet. Since last bigger discussions few changes happened 
on the SCL field -- new version of scl-utils implements some of the 
features, that were mentioned as blockers before and discussion about 
SCL prefix could be hopefully closed by updated prefix reasoning, a 
story that explains what the prefix means 

Missing piece to finally have SCLs in Fedora is still some guidelines 
that the SCL will have to follow, defining processes how to approve 
packages (whether a formal review will be necessary and what would the 
review include).

Page that sumarized the open questions few months back (so some latest 
updates may be missing):


More information about the env-and-stacks mailing list