Council Engineering update
Honza Horak
hhorak at redhat.com
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 (https://git.fedorahosted.org/git/rpmgrill.git) 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:
https://fedoraproject.org/wiki/User:Hhorak/Draft/task-rpmgrill-copr
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.
https://fedoraproject.org/wiki/Env_and_Stacks/Projects/FunctionalAndIntegrationTests
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
(https://www.redhat.com/archives/sclorg/2015-February/msg00022.html).
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):
https://fedoraproject.org/wiki/Env_and_Stacks/Projects/SoftwareCollectionsInFedora
Honza
More information about the env-and-stacks
mailing list