This is part three of a series based on talks in February at DevConf in the Czech Republic. You should start with Part I, ”Why?”, particularly if your first response on reading this is to… ask why. That part covers the background and outlines some problems we are trying to solve. Part II, “What’s Happening?” talks about accepted proposals (and connects them back to “why”, again). This week, governance structure, current status, and some big-picture ideas. Then, next time, the panel discussion, and finally, Q&A after that.
As before, you can watch the video on YouTube, but there are a few reasons you might want to read this instead. First, videos are hard to skim or search. Second, time moves on and this contains
a few many updates (which I have marked with Update, so if that’s all you care about they will be easy to find). And finally, I made some embarrassing typos on the slides, which I have fixed. You can see those slides on my web site, starting with slide 18. This portion only covers three slides, but also a full third of the time: I talk a lot. (And, there’s quite a lot of new material.)
The Video, Further Continued
(For this article, we start at 22 minutes, 18 seconds in.)
This is the governance structure we’ve set up for the distinct Fedora products and the different “rings”. (Make sure you’re familiar with Part II of this series or this will all be very confusing!)
I come from a personal background where decisions are made in consensus communities after a lot of talking, and so maybe I have a predisposition for that. In any case, that’s how the new Working Groups are set up — we created five new committees, which has some people putting their palms to their faces and muttering More governance? Is that really going to help? But, I think it really will, and here’s why.
The idea for this structure came out of my work in Fedora’s Cloud SIG. If you’re not familiar with the idea of SIGs in Fedora, basically, a SIG is a very lightweight construct where you say “I want to have a Special Interest Group”, you make a wiki page for it, and maybe you request a mailing list for it, maybe you don’t — and there, you have a SIG. This is a great, flexible structure for doing open source. EPEL (the Extra Packages for Enterprise Linux repository, an immensely popular Fedora subproject) went from having a formal board and so on to being a SIG, because it works pretty well for a lot of things.
But, a SIG can easily drift out of maintenance because it’s easy for no one to feel real responsibility for it. In Fedora Cloud, it ended up with me doing almost all of the consistent work… I’d call for volunteers to do things, and people would show up and help (and make very significant contributions), but then they’d drift out again, and I think people never really felt where they could fit in to the ownership.
So, the idea for the Working Groups was to have committed, active groups, where we called for volunteers, got nominations, and assembled the people with voting responsibility, where there are voting-type decisions to be made. The groups will have regular meetings (or at least, regular communication), and these people have signed up for some accountability — but that doesn’t mean the greater SIG that is associated with that area is gone. We still welcome everyone to participate, it’s just that these people know their names are on the line for it. And, if you want to talk to someone who is invested in that way, you can easily know who they are. You can talk to those people, and you know what the framework is. (Update For the curious, the membership for these Working Groups can be found in the project wiki: Cloud, Server, Workstation, Environments & Stacks, Base Design.)
The idea is really to make more people feel empowered, not to introduce more bureaucracy. And, as Fedora continues to get bigger, some of the things that FESCo currently does can be delegated. FESCo meetings won’t be four hours every week, because many of the technical decisions can be offloaded to these working groups, so it’s a structure that’s set up for growth.
SIGs are still a thing, and the other sub-projects and teams in Fedora — the Fedora Packaging Committee, Design, Quality Assurance) — those are all still here. Exactly what their role is, how they fit into the project… that may change a little, but it’s going to change as part of a community collaboration. No one is saying that we are disbanding anything, and we still value all of these contributions and the groups all have an important part to play in Fedora.next.
Update Fedora QA “community monkey” Adam Williamson wrote a nice blog post reflecting on Fedora.next as an additive process, and since I think it’s dead-on and articulates some things I had been thinking but not saying very well, I highly recommend it as extra follow-up reading. (You didn’t expect homework, I know. Don’t worry; it’s short.)
Update It’s two months later, so quite a bit in this section has progressed from what’s in the video: much of what was future tense is now past and present.
We started with this: each of the product working groups produced something we called a “PRD”. That’s a kind of business term — a PRD is “Product Requirements Document“, and since we don’t actually have any products that we’re going to in any way sell, it’s not quite as formal all that. But we did want to make them a little more deliberate and structured than we ever have before. Basically, each is a description of what we are planning to do with Fedora Cloud, with Fedora Server, and Fedora Workstation.
At the time of the talk, these planning documents had been approved by FESCo but had not yet been reviewed by the Fedora Project Board. Update They’ve now been approved by both bodies. This is important because, obviously, this is all a big strategic shift, and those of us involved in the planning wanted to make sure we followed the proper process and have affirmation that we’re going the right way. (And along these lines, the KDE-based “Fedora Plasma” proposal is still waiting on Board discussion; I’ll include more on that as it develops.)
You can see these documents for each working group on the Fedora Project wiki.
For the next step, each group discussed the practical changes that their product will actually mean for the next Fedora release, Fedora 21 (due out this fall, sometime around Halloween). In the future, it may be that the different products each have an independent release schedule, but we decided to keep them in sync now, because changing too many things at once is dangerous, especially when (if you’ll remember back to the beginning of the talk) Fedora has gotten pretty awesome at putting regular releases every almost six months. For the same reason, what you see in F21 won’t necessarily be the grand realization of each vision — but we’ll have meaningful progress.
Then, these change ideas were broken down into Change Proposals, with a capital C. These are part of the Fedora Release Planning Process, which is a whole talk or article on its own, but in short, these proposals are our way of coordinating development across the project. Each is reviewed and approved (or, sometimes, rejected) by FESCo, and that’s what we’re in the process of going through right now, with coordination from fearless Fedora Feature Wrangler Jaroslav Řezník.
The accepted Change Proposals (including those from other parts of the project) form the roadmap for Fedora 21. It’s not all set yet, but the overall picture is becoming a lot more clear as proposals go from vague handwaving to actual plans for things to build, code to write, processes to reengineer — and as we get commitments from project members who are excited to do those things.
(If you’re inspired by any of this, or inspired to do something which I haven’t even mentioned, Fedora has a lot of room to get involved. You can easily join Fedora if you’re not a contributor already, and if you are but aren’t quite sure where to help, talk to me or anyone else involved in the project in an area that interests you. We’ll hook you up.)
But Wait, There’s More!
So, those things — the products, the Environments & Stacks and Base Design rings — are, so far, the most visible, obvious changes that make up Fedora.next. But there are more things which I like to include under this umbrella. Not everything has to have this brand, of course, but, in a way, everything that’s in the future decade of Fedora is what we’re talking about when we say “Fedora.next”. It’s not specific little ideas, but the big direction setting. So, these are some other areas which I think are important to where we need to go.
We really have very little of this in Fedora Quality Assurance and Release Engineering, and in order to deliver three separate products, and in order to address any needs beyond those products, we really need to step it up.
And, we are. The QA team is working on a system called Taskotron, to do automated testing, both for packages and distribution-wide. This is based around Buildbot, an open source Continuous Integration framework, but with features beyond that and integration into our environment. The QA team asked for extra time to work on this, and that’s part of why Fedora 21 has a longer-than-usual development cycle.
Also, Fedora Release Engineer Dennis Gilmore gave a talk at DevConf on Building an Agile Fedora Release Engineering, where he covers change related to Fedora.next, and puts out a call for people interested in contributing. I encouraged people to attend that talk in February, and if missed it but are interested, I encourage you to watch the video now and contact the Rel-Eng team to get involved. A lot of what’s currently done by hand needs to be made more automatic, and there are many areas which could use optimization in order to better handle Fedora’s growth.
HyperKitty and the Fedora “front page”
Fedora has some communication issues — each part works fairly well, but we have a lot of separate areas which we don’t always communicate across. And the Fedora devel mailing list has always had a lot of noise, making it hard to pick out the signal. HyperKitty is a web-based interface to our mailing lists. Again, it’s additive. It doesn’t take the mailing lists away, but it lets you interface with them in a modern way. If you like the old way, cool — still there. But if you want something more, this is not just prettier but enables features that we can’t do with mailing lists.
Designer Máirín Duffy gave a talk about HyperKitty at LibrePlanet 2014, and you can see the slides for that (with video hopefully coming soon. There is also a staging instance online. Be aware that it’s running on underpowered hardware and is only periodically synced with content from the the real lists, so don’t set your expectations too high, but you should be able to get feel for what it will be like.
I also have this idea which Fedora Engineering development ninja Ralph Bean dubbed “Fedora Front Page”. It’s basically an aggregator of everything that’s important in Fedora right now, a kind of stream of content that’s currently important across the project and specifically information that’s of interest to you as a Fedora contributor or active user. Right now, if you go to http://fedoraproject.org/, it’s a very pretty front page, but Fedora contributors probably never look at it, and Fedora users might visit it a few times, think “oh, this is a nice brochure”, but never look again. It was designed to be a brochure site, and it really does that well, but I think we need something that is more of an active center. The Internet, these days, is of course centered around the web, so we should move our active center out of being mailing lists and IRC onto a web site.
Update The Fedora Design team and Fedora Websites have picked this up. I’ve covered it a bit in my Five Things in Fedora This Week posts, but the best place to learn more is Máirín’s blog — see A proposal for Fedora’s website (considering Fedora.next). She and Fedora Designer Ryan Lerch call this part the “community hub”. I’m excited — this is going to be really useful.
COPRs, Fedora “Ugly”, and EPIC
You’ve probably heard of COPRs by now. Basically, this is personal package repos that anyone can create, with a very low barrier to entry.
Update This is in production now. The website is at http://copr.fedoraproject.org/ (and I guess we are spelling it “Copr”, with no s and fewer capitals). There’s actually a nice introductory blog post over on Red Hat’s developer blog — see An Introduction to COPRs, and since this whole article series is nominally a recap of DevConf, you should also watch developer Miroslav Suchý’s DevConf talk.
The next thing is “Fedora Ugly” — an idea that came up at DevConf. It’s a way for software to move from Copr towards the main Fedora distribution, where packages are integrated together in a way that Coprs aren’t, but yet not having to climb the high wall that is getting into Fedora distribution proper. So this is a practical way we can do that thing I was talking about, where we have packages that aren’t pretty, but we still include them in Fedora the project and make them better while they are part of Fedora — rather than saying “you can’t play with us until you are perfect”, which is really our current approach.
Update This, too, is happening. As you’ll see from the question and answer section later, people weren’t really fond of the “Ugly” name, and the Environments & Stacks Working Group settled on “Playground”. Their initial plan is up for wider discussion now, and the official Playground Repository Change Proposal will go through FESCo review as explained above.
And, “EPIC”. This is an idea from Fedora Project Leader Robyn Bergeron for a repo that fits between EPEL’s 10-year RHEL-matching lifespan and Fedora’s fast moving cycle. That’s Extra Packages for Infrastructure and Cloud — of course, mostly to make a cool name. Update And this one is championed by Fedora project member and long-time EPEL contributor Stephen Smoogen — if you’re interested, vote for his “EPEL.next” talk for this summer’s Flock to Fedora conference. (And I hope it’s not too gauche to at least suggest that if you’ve read this far in the series, you might be interested in voting for some of the other Fedora.next proposals as well.)
Next… an easy, quick docs site. Fedora’s project wiki is a tool that’s used for a whole bunch of different things — a lot of it is process documentation, a lot is guidelines for Fedora developers, a lot is active pages used in actual workflow. Mixed in with that there’s some user documentation, but if you want to find user documentation about Fedora, good luck finding it with a search. Someone basically has to point you at it. And then if you click on some link and go out of that maintained part of the wiki, you are in crazy-land and could easily land on anyting: outdated information from six years ago, or worse. It’s a big mess, and it’s really so bad that’s a barrier to even getting started in contributing, so I think we need something new that’s clearly separate.
The other side of this is the Fedora Docs project (http://docs.fedoraproject.org/ — this is excellent, almost book-level documentation. It’s very high-quality, but it’s also created through a relatively heavyweight release process, so if you want to contribute to the documentation in that way, you’re kind of committing to a joining a whole subproject that has its own processes and culture — and there’s nothing wrong with that, and everyone who does that is awesome, but, if you just wanted to throw up a quick HOWTO, Fedora isn’t really equipped to accommodate that.
The Fedora Docs people are aware of this, and have ideas for making this better, so if you have suggestions, you can talk to me, but even better talk to them about helping. Update Yet another thing which is moving forward. Docs team lead Pete Travis has a blog post about a recent activity day focused on new contributors, and the Fedora Cookbook came out of that. Read more at Pete Travis: Open Books, and watch for more about it in Fedora Magazine soon.
Watch for Part IV In Two Weeks
Next week I will be at Red Hat Summit (at the Fedora booth, of course, and wandering around DevNation), so while there is a chance I’ll have the next installment ready, I don’t want to promise and then not deliver. So, let’s say the next week. I’ll cover the Working Group summary presentations, and the week after that, questions and answers (from both this talk and from the panel discussion).
And I’m going to find some more pictures. Without the slides to break things up, this is getting a bit text heavy. Sorry about that.
As before, let’s continue this conversation in comments and replies, and in addition to responding, I’ll distill that into a final Q&A post at the end of this series (separate from the summary of the questions at the conference).
One thing I never see anyone working on is a proper universal packaging system that works for all distros. I’ve heard people trying, but nothing ever happens. The .deb vs. .rpm war is far too old and far too stupid to even matter, but it does. It causes so much extra work for everyone.
Someone should step back and build a proper Linux Installer that stops looking at the distro/repo way of doing things and instead works in the opposite direction. Where there is an installer standard that the distros have to conform to. (example: Linux Packaging Standard v. 1.4) then has a set of standards that the distros have to conform to. Distros then have to be LPS v 1.4 compliant for the installer to work. Then everyone can stop all this nonsense and work together. Then the repos can be universal and can work on every platform that conforms to the version standard number. Possibly the standard can be controlled by The Linux Foundation, and make releases and updates. It would be awesome if Linus got ticked off one day and wrote a new Git-type system for the installer.
This goes a long with an argument that I’ve said before. Fedora is losing mindshare to .deb distros. You guys want to gain users and are doing a lot of research and meetings to change the way you’re doing things. Well unless you just want developers and CS geeks using your product you’re going to have to start looking at this from the average joe user that wants to install Fedora on his old XP machine, without having to know what a repo is or what an RPM or DEB is, or else you’re going to just end up being second place to .deb based distros… slowing becoming even further insignificant to computer users. I can see Fedora becoming a distro exclusively built for geeks and people that want to pick away at code and stuff.
The reason why I’m bringing it up here is, Fedora is a trend setter. They do a lot for the future of all things Linux. It is a community distro that has great devs and is backed by the number one Linux Company (I know arguably, but still noteworthy no matter who you are). You guys are very important to what happens with the advancement of how Linux progresses. systemd, Wayland, whatever… you guys always seem to be at the lead of all that is trending in Linux, but there is never a solid fix for some of the issues that keep Linux from being adopted by the every day normal user that ends up going to Windows 8 instead of Linux.
There are some things as a user I just don’t want to have to care about. I don’t care about the installer or the packaging system involved. I want the software I’m installing. Free vs. Non-Free vs. Proprietary vs. stupidly priced Adobe CS5! I want the software and I just want it to work. I don’t care how it gets installed.
Anyway, just another idea for you guys… even though I know nothing will ever come of it. :/
Something can come of this, or any other constructive idea. You just have to start to work on it, because wishing someone else would just doesn’t get very far. If you can get people inspired by what you’re doing, others will join in and it will snowball.
On the packaging system in specific: I don’t think the package format has much to do with it. OpenSUSE also uses RPM, but are packages aren’t interchangeable. So, it’s not really down to deb vs. rpm vs. some new thing. But, actually, the “Linux Packaging Standard” you are talking about already exists. It’s called the Linux Standard Base, and version 5 is in slow but active development right now. It’s not a perfect standard, and there are some serious issues which I won’t get into here because it’s a long topic, but the point is that people are actually actively working on this approach.
But that said, for most applications and services, I don’t think this is really the level that is important or will ultimately matter. The new approach is containerization. On the server and software developer side of this, the current darling is Docker —
and try it out — and for desktop applications there will probably be a similar container interface, made more likely to be cross-distro by the wide adoption of systemd. See this talk for more on one possible way this might be done.
Sorry, I didn’t mean to sound so negative. I was meaning that this is an ongoing issue where some software packages aren’t available for some distros for whatever reason and just because I suggest something doesn’t mean it will automatically be the one thing that gets everyone to finally agree and adopt a specific way of doing software installs.
I am currently half-way finished a three year CS course and will be contributing to some open source projects as soon as I graduate. I’m too busy right now with homework and assignments to focus on anything else at the moment. Which is why I offer suggestions and ideas.
I offer ideas because I want to contribute and sometimes I think that I’m far enough away from the code to see some of the things that you guys might not. I know that is highly doubtful, but I somehow manage to feel like I’m contributing even though it’s coming across as a negative complaint.
I appreciate everything you guys are doing to make Fedora the best it can be… (and all the other open source projects you help develop). Even though I don’t always agree on which direction you’ve taken (Gnome 3) or how you view things, I appreciate it. I am one grain of sand in the dirt pile, but I know that a pile is created by many individual grains. I want to be a grain that contributes and doesn’t just complain.
I guess what it boils down to is, I have a passion for this project. I have a passion for open source. I believe in it so much that I’ve completely changed my direction in life so that I can one day contribute to the cause with real code. I complain about things because of that passion. I want it to succeed and when I see things that are standing in the way of its adoption, I get upset for it, not against it.
And I don’t mean to imply that ideas aren’t welcome. I appreciate your passion — a passionate community is vital for the project. I just think that the world has moved past the point where rpm vs. deb was relevant, so I am not personally worried about it as a priority. But if you disagree with and want to do something about it, you certainly can have an effect. I do suggest you take a look at the LSB, and the application container technologies I mentioned. Maybe it turns out that Fedora activism in future LSB development is just what we need. We’ll see. 🙂
I just spent the last hour reading about Docker. It seems almost too good to be true! If it is true, you’re right, the .deb vs .rpm war will finally cease to exist! I don’t funny grasp the full concept yet, but all the ambition and all the promises seem amazing. They’re also saying that with Docker Linux apps will work on OSX as well.
This is such a great day! 🙂
Now all that’s left to do is merge all the GUIs and merge all the Distros! HA! (That was a joke).
>Also, Fedora Release Engineer Dennis Gilmore gave a talk at DevConf on Building an Agile Fedora Release Engineering
Unfortunately vide is not available by link. Is it possible reupload it or point on some blog post with short description?
Looks like all of the DevConf videos — and in fact all of the Red Hat Czech YouTube channel — are offline. I’ll check into it.
Thanks Matt for checking into it! Do you have any news on that?
Yes — looks like Google took the channel down over some sort of bureaucratic thing. They’re working on it and hopefully it’ll be back soon (or else posted somewhere else).
you may want to add a forward link to part IV-a
Hope this is germane and not ignorant.
I will be installing a Solid State Drive (SSD) on my Personal Video Recorder (PVR) client and it almost certainly will not have Fedora. No Long Term Release (LTR). I want a graphical interface, security and client software and that is it. I don’t see the need to thrash the SDD every six months for a new release (which would bring few if any advantages to this application).