Fedora Present and Future: a Fedora.next 2014 Update (Part IV.a, “Base Design”)

This is part four of a series based on talks at February at DevConf in the Czech Republic. This week, I was going to cover all of the reports from each of the Working Group liaisons, but that turned out to be quite a wall of text, so I’m going to do them one by one, starting with Phil Knirsch on the Base Design.

If you haven’t read it already, you should start with Part I, ”Why?”, and if you enjoy the general concepts of “logical progression” and “putting the horse before the cart”, I suggest following that with Part II, “What’s Happening?” and then Part III, “Governance, Progress, and More Ideas”.

You can watch the video on YouTube, but you may find the text more helpful. I’ve summarized and paraphrased instead of just transcribing. And, since it has been two and a half months, I’ve gotten updates from each speaker.


Working Group Report Video


Quick note: Who are these people?

This panel session features the FESCo liaisons from each Working Group. FESCo is the Fedora Engineering Steering Committee, and the Working Groups are independent subcommittees of that group. Each group’s liaison isn’t (necessarily) the leader, but is tasked with coordinating inter-project communication at that level. Since all of the liaisons were in Brno for the conference, we got together to talk.


 

Base Design: Phil Knirsch

Phil starts with the mission of the Base Design:

The goal of Fedora Base is to provide a standard platform with common technologies, frameworks and APIs for all Fedora products

although he notes that “all” seems rather strong, especially considering that there might be more products in the future.

Phil adds that Base itself as a design is not supposed to be and won’t be released as a product in itself, but that the Working Group has identified some concrete goals extracted from that mission:

  • The first definition of the Base includes: the Anaconda installer as a standard mechanism for all of the products, the compose tools used by release engineering to assemble the products, a minimal install (yet to be exactly defined, but beneficial for Cloud and possibly for eventual products in the embedded space), and general functionality used by the majority of the products.
  • Based on feedback from other Working Groups, Base will provide API and/or ABI stability for a specific release, rather than focusing on simply package versions/releases. (API stability means that code written for one version will continue to compile; ABI stability means that binaries will continue to run.)
  • The user experience of functionality provided by Base is expected to be consistent across different Fedora products.
  • Keep base as small as possible, while still providing the functionality that most products will use.

This has led to a few initiatives in progress now:

  • Cleanup of package build dependencies. The plan is to have Base to be self hosting, so that it can build itself, and be self-contained and self-sustaining. If you tried to do that right now, you’d end up with about 1,800 packages, which sounds rather insane — and it is! So, the build requirement cleanup, after the first review that Harold Hoyer and Phil did, would get us down to maybe a couple of hundred packages. Without self-hosting, we’re already down to 127 packages.
  • Cleanup of package scripts. Every package can have “post” and “pre” scripts which run when a system is installed. Because of the way RPM is designed, these can be any arbitrary commands. This is powerful, but also messy — and can be slow and fragile. The plan is to provide more standard macros for common things, and to remove scripts that aren’t really necessary.
  • Involvement with other WG efforts. Base Design will collaboborate with the other Fedora Working Groups and their PRDs, Tech Specs, and Change Proposals, to ensure that Base contains all of the relevant parts, and work with Release Engineering and other groups to make sure that the necessary tooling is in place.

Phil notes that these are just examples of initiatives that come out of this. Base in itself is going to be defined by the requirements of the products — whatever they need, and have in common, Base will provide, and that in time the activities will likely grow.

He also invites everyone to participate in in the group’s (typically) regular weekly meetings on

#fedora-meeting

on the Freenode IRC network, Fridays at 15:00 UTC.


Watch for more of Part IV Next Week

I’m not really trying to drag this out forever, I promise. There’s just a lot to cover. Coming up, the summaries from Environment & Stacks, Server, Workstation, and Cloud. Since these are shorter than the earlier parts of this series, I’m going to try to do them at a slightly faster pace than only one a week; we’ll see how that goes. In any case, once the summary presentations are done, it’s on to Q&A.

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).

Fedora Contributor Community Fedora Project community

1 Comment

  1. Cory Hilliard

    Being that you now have three separate “parts” of Fedora all moving and evolving at separatly, (with the third being further split into three separate distros), would it not make sense to have a rolling release? It would be a nightmare to constantly keep all of these parts hitting the same 6 month goal.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions