Flock 2014: Over but the work is just starting [Aug. 10th, 2014|02:23 pm] jwboyer

It is traditional when you go to a Fedora conference to do blog posts about your experience there. I think they're great, and I've enjoyed reading those posted by others. There are some great talk recaps and it's always interesting to see how people are spending their time.



For one reason or another, I'm not one of those that manages to do this on a daily basis though. That usually means I try and do a week long recap of what happened, and the information is largely stale or redundant and I don't think it makes for great reading or communicating. I thought about this a bit and I think instead I'm going to talk about what I'm planning on doing now that Flock is over that came as a direct result of things that occurred while I was there. Hopefully that will be a bit more entertaining and really keep me honest with those plans.



Custom Kernel builds



A number of people came up to me and asked how to build custom kernels. The instructions we have on our wiki page are probably fairly valid, but I really expect that they are stale in certain areas that lead people to have trouble. The kernel maintainers never really build kernels the way the wiki page suggests, so it might be time for a revamp. I'll look this over and give some examples of common cases (enabling config options, adding patches) and hopefully this will lead to people having fewer issues.



A Fedora kernel git tree



We've often talked about having an exploded source tree. The problem with that is that it's of little benefit to the Fedora kernel maintainers. Koji builds from the SRPM and that's from the tarball, patches, and spec file. However, getting a kernel tree created is likely only difficult from the start, and keeping it maintained could probably be automated. It would have to rebase the branches, as that is literally what we do in the SRPM, but if people find it useful and it isn't overly difficult to create, we might as well try. Plus, it's a good way to spend a day or two when I need a break from the daily grind.



Packaging changes



A couple people spoke with me about some possible packaging changes for the kernel. Things like the kernel-source package that Fedora shipped long ago. To be honest, not all of these will probably happen but there are a few minor things we'll likely change.



Bug workflow



Unsurprisingly, this is one of the larger topics I left with things to work on. For starters, we want to try and automate some of the triage we do. It shouldn't be massively difficult to write something that parses an oops and figures out the correct part of the kernel it came from. We'll likely start with ABRT bugs, since those are mostly formatted in a uniform way and work from there (we might even be able to get ABRT to do this at some point as well.) We can also pull from the retrace server once that is able to filter out results. This is a pretty broad description of what to do, and that's because there are many options and directions we can take. Hopefully some automation will really help us get time back to work on different things.



Rawhide kernel handling



In my kernel talk, Owen asked me "Is the rawhide kernel the right kernel for rawhide?" He was referring to the fact that we build with debug options enabled, and this has performance impacts. Those impacts are less noticeable to a human now that we leave SLUB debugging off, but if you're using perf or some automated performance metrics it is going to be easy to see it as slower than a normal build. Even ignoring the performance aspect, there are still days where we'd like to get a build out for "adventurer" testing before it hits the main rawhide compose, but we don't have a great way to do that. I'm going to think about how we can use the kernel-tests repo, the autotest harness we have, and some of the other tools to see if there's a way we can improve both the rawhide kernel quality and the number of people willing to test rawhide kernels. Nothing concrete yet, but I think some of the work we've done over the course of this past year will really help.



Fedora Governance



This really has nothing to do with the kernel. The discussions I had over the course of the conference around governance were really good. The dedicated session Toshio and Haikel held was well attended, and participation was excellent. I'm looking forward to working with the broader Fedora community to hammer out the rest of the details in the plan and start executing on that soon. There's a lot of work to do, but out of everything at Flock it's the one thing I am most eager to jump into. I honestly wish I could spend more dedicated time on working on broader Fedora issues in general.



I'm sure there are things I've forgotten. If I talked with you about something that isn't on this list, send me a reminder. After a week of meetings and conference, my brain can get a little full.



As always, the best part of Flock was see old friends again and meeting new people. I had good conversations with everyone I spoke with, and it was a really great time. If you haven't already, be sure to thank the Flock organizers. Having pitched in a bit over the past 2 years, I can tell you that it isn't at all easy to get this conference planned, and it can be exhausting while it's running.



Looking forward to working with everyone over the course of this year to see what awesome things we can bring to the next Flock!