This year I had the opportunity to attend Flock to Fedora for the first time. I had previously attended two FUDCons in the LATAM region, so this was a new experience for me as this conference only takes place in the North America and EMEA regions. Flock 2017 itself had a different focus, that is, do-sessions rather than just talks.
I will focus on three sessions that I attended, those what were of particular interest to me and from which I learnt the most.
How to add tests to your packages
This was a workshop on adding tests that are written as Ansible playbooks to Fedora packages. This is done by adding a tests directory in the dist-git repository for the package or module, and anyone will be able submit pull requests for any package to add tests via Pagure once the proper infrastructure is put in place, but for now, you need to create a repository in the https://upstreamfirst.fedorainfracloud.org repositories.
We were first shown a simple example for adding tests with the gzip package. All the steps are documented in the wiki at https://fedoraproject.org/wiki/CI/Tests#Testing_specific_RPMs. Since I had no previous experience with Ansible, I had to learn the very basics during the workshop itself, but that was good enough for this session’s purpose.
I started working on adding tests to one of the packages I am a maintainer for: nik4, a tool to export OpenStreetMap data to raster image formats. I expect to be able to push them very soon as I still have to figure out what input file would cover the most important corner cases and how to setup a database for the test pulling the minimum amount of packages. Since there are on tests at all in %check for this package, there is no need to migrate them to the CI infrastructure.
Fedora kernel process review
This was an open session with no actual slides or material to be presented as this was more discussion-oriented. Several issues were discussed, namely arbitrary branching (something that will not affect the kernel package), non-Red Hat participation in Fedora kernel maintenance, and alternative architectures (as of now cannot be shipped on Copr was builds take too long and timeout), but most of the time was spent on the workflow for fixing kernel bugs.
The Fedora kernel is not very different from upstream, as there are just about 80 out-of-tree patches applied to the kernel shipped by downstream. Users are welcome to request new modules to be enabled via Bugzilla, as long as they have a good reason for it.
Currently there are only two kernel maintainers who are full-time employees at Red Hat, and they have to deal with a whole bunch of very low quality bug reports, specially from ABRT, which are mostly ignored. Their main priority is to have CVS covered. A major problem is that the kernel team does not have a variety of hardware for testing, so having more users running the tests from the Kernel Testing Initiative will help to catch more hardware-specific bugs.
An idea that came out of this discussion was to organize a Kernel Test Day as part of the schedule for every Fedora release starting from F27, so we are expecting to see this happening on September after the Linux Plumbers conference.
I also attended very interesting sessions on modularity and Fedora Atomic. I found myself writing a Dockerfile for python-spyder for submission for review, that still needs some work. I also got a Fedorator that took back to Nicaragua and is ready for events, thanks to Neville Cross.