Flock 2013 Con Report

My god, it’s full of stars!

So as most of you probably know, this past weekend was Flock, the first of a new breed of Fedora conference that replaces FUDCon. It was reasonably well-attended (the count I heard was about two hundred). Among those that attended were nearly all of the well-known members of the Fedora community. I’m sure some (many?) of them will also be summarizing their experiences, but I want to get my notes out there while it’s still fresh. This is not a comprehensive overview of Flock. If that’s what you’re looking for, Máirín Duffy has provided an excellent set of blog posts including the recordings and transcripts[1].

The first three days followed a pattern of talks/lectures before lunch and workshops or hackfests in the afternoon. There were a great many sessions (usually eight or nine running concurrently at any time) and this made it somewhat difficult to see all of the useful content.

There were a great many interesting talks, but I’m going to focus this report on the three that I think will have the most lasting (and widely-felt) impact on the Fedora project as a whole.

Updates Model

The first here was Tom Callaway’s proposal of changing the default updates delivery method. As he put it, currently Fedora users are “drinking from the firehose”. All updates are delivered as soon as they hit the stable updates repository and it feels to users like they are in constant flux. Tom’s proposal is that instead of a constant updates stream, we should shift to delivering important[2] updates as part of a monthly update set. Security issues should still be released in the current model, so that users get those as quickly as possible. There was some debate over whether security updates should be installed automatically or just notified, but that was left unresolved. The set of “important” updates should be rolled up as a bundled collection of updates that is prepared a week before the monthly deliverable and offered for testing as a complete set. Package updates outside this set should be made available similar to the way Microsoft does its “optional” updates. They can be selected manually (or in bulk) in an updates tool if the user wants them. We believe that, by having the ability to tests updates as a set we will be able to reduce some of the instability the arises throughout the Fedora supported lifetime as well.

Tom’s proposal dovetails closely with the next two proposals, one from Matthew Miller and one from myself. Matthew’s proposal is fairly well-known at this point. It involves redefining Fedora into a set of policy rings wherein we can tighten or relax the packaging rules in order to make it easier to run applications and SDKs in or on Fedora. I won’t go into great detail on this proposal, as it’s been discussed at great length on other lists. I will say that the Fedora community as represented by Flock attendees was receptive and very much liked the idea of relaxed packaging requirements at the higher levels of the stack, as well as being able to layer projects atop other foundational pieces (such as OpenShift Gears or Software Collections).

Fedora as Products

The final proposal was one that I came up with and discussed with Robyn Bergeron and the RHEL architects shortly before Flock. The general idea behind this proposal was to stop trying to treat Fedora as “everything for everyone”. Instead of our classic approach of building all projects in Fedora as a single collection of packages, we should instead focus on a set of specific constituencies and serve those needs directly and completely. To that end, I proposed that we should build three products from the Fedora family with very specific target audiences and then work with Matthew’s proposal to layer other software atop these products in a sensible way.

Fedora Server

Target: People for whom RHEL and CentOS don’t move fast enough, and people who want to see and influence the future of RHEL
Purpose: Build a better RHEL, and engage customers in development of RHEL, OpenStack, and other emerging technologies.

One of the key points here is that we would start making it clear that Fedora Server is the development path for RHEL 8. Disruptive changes made to the Fedora Server would be carefully scoped out ahead of time. We want this to be the place that we can engage application developers and tell them “if you want something from RHEL to enable functionality for your application, this is where you build it”.

Fedora Cloud

Target: Development; DevOps in production; OpenShift
Purpose: We do not become entirely irrelevant.
This should be mainly a proper subset of the Fedora Server, with some few additional packages for acting as a virtualization client. The goal here is to provide the definitive operating system for running in a PaaS environment like OpenShift. This is the fast-moving DevOps platform that people who are doing rapid develop-and-deploy with high resiliency would want to use in production.

Fedora Workstation[3]

Target: Creatives, Developers, Sysadmins, and other IT professionals
Purpose: Keep Linux users on Fedora (This is a niche market; we recognize that. But let’s make it our niche.)
This is the platform upon which we would want people to be doing useful work in the Fedora/RHEL ecosystem. It’s where the “makers” and IT professionals should be able to get their work done. This is also the product that would have the most leniency in making disruptive changes (the most obvious forthcoming one being Wayland). That is not to say that this should be “Rawhide in disguise”. The goal here (as with the other products) is that this should be a stable and useful workstation that enables the user. It is not a playground, nor is it a general-purpose desktop.

Tying it together

The responsibility for defining the specific requirements placed upon each of these products would be placed upon a working team (chaired by a FESCo member) for each product. The proposals presented therein would require approval and then would become essentially a constitution for that team. The specific details of how this process would work are still being worked out. All of this is contingent upon acceptance of the overall plan by the Fedora Advisory Board, who will be receiving a formal proposal in the next week or so.

Last Day

The fourth day was dedicated to hackfests. I spent the morning working on Kerberos-related hacking on the fixes for the new kernel keyring support and then the afternoon in Matthew Miller’s “Hack the Future” session discussing his and my proposals for a new, more targeted Fedora design. In this latter discussion, we came up with most of the above plans.

It is worth noting that while the overall reception of these plans was positive and encouraging, there were individuals from Fedora Release Engineering and Fedora Quality Assurance teams that fear these changes will strain their already-limited resources. This is a valid concern and will be addressed. We’re looking at ways to reduce the impact on these two teams (such as by increasing automation and re-using existing capabilities wherever possible) as well as possibilities for providing increased resourcing. No plan will go forward without consulting these two groups.

If you have read this far, I thank you. I know it’s a bit wordy.

Notes

[1] http://blog.linuxgrrl.com/category/fedora/flock/
[2] “Important” should be left intentionally vague at this time.
[3] There is debate over whether to call it “Workstation” or “Client”, but we all agree that “Desktop” is not the right name. I’m in favor of Workstation, so that’s what I’ll use here.