DevConf CZ, Events, Fedora Project community, General News, Past Events

Fedora Present and Future: a Fedora.next 2014 Update (Part IV.b, “Environments and Stacks”)

This is the continuation of part four of a series based on talks at February at DevConf in the Czech Republic.  Last 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, with Marcela Mašláňová from the Environments and Stacks Working Group this week.

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 three months, I’ve gotten updates from each speaker.


Working Group Report Video


Environment and Stacks: Marcela Mašláňová

Marcela explains that, like Base Design, Environments and Stacks is not a product in itself. It exists to serve the other products, and it does this through new or improved methods for developing, testing, packaging, and deploying software for the Fedora community.

One part of this is thinking about is improvements to Fedora developer’s lives, and what is missing there, so an early focus is improved documentation for Koji (the Fedora package build system) and for COPRs (our system which lets developers easily manage and host their own small package repositories).

Another big area is SCLs. This stands for “Software CoLlections” — a way of packaging specific versions of languages like Ruby or Python into the /opt directory, where they don’t interfere with a system version of that same language (more at the Software Collections “upstream” web site). This is very different from any previous way of packaging things in Fedora, so the group is working with the the Fedora Packaging Committee (FPC) to develop guidelines for providing these within the distribution. Both the Cloud and Workstation groups have asked for this as important for their audiences. (And an update on this: the Ruby 1.9.3 collection, with Rails 3.2.8, will be the first available.)

The next area is the “Fedora Ugly” or “Fedora Incubator” repository, which I spoke about briefly at the end of my talk (see Part III, “Governance, Progress, and More Ideas”… scroll down to the last section). This is a space within Fedora for packages which, for whatever reason, do not meet the standards of the main repository. The two big big updates on this are that first, the naming has been settled and the repository will be the “Fedora Playground”, and second, this has been officially approved by FESCo (the Fedora Engineering Steering Committee) and will be a feature in Fedora 21 this October. More details can be found on the Fedora project wiki.

Marcela says that the group has many plans and future ideas. There are many possible improvements for automated packaging, reviews, and QA; improvements in build systems; better integration of services; and more and better documentation. What can be done for the Fedora 21 timeframe must necessarily be a smaller scope, so SCLs and the Playground are the first focus. In the future, this will expand as the needs of the other working groups and the associated products develop.

Visit the Env and Stacks page on the Fedora Project wiki for further information, including the mailing list and IRC meeting times.


Watch for more of Part IV Next Week

Coming up, the summaries from product-based working groups: 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).

5 Comments

  1. Hunkah

    I’m starting to get a little confused by all this. COPR, Playground, Ugly, Incubator, Software Collections, repos, containers… you guys aren’t making any of this easy for users to understand… and I’m a full-time user of Fedora. I think some maps or pictures might be needed for those of us not neck-deep in code all the time.

    • Well, fortunately, Playground, Ugly, and Incubator all end up being different possible names for the same thing. :)

      Some of this is just the nature of software (not even just Linux distributions). We integrate a lot of different technologies, so we get a lot of different ideas and names whether we like it or not.

      But I hear you about needing some visuals. Is there a particular area that you think it’d be helpful to illustrate?

  2. Hunkah

    I guess just knowing which repos mean what. Like if I’m a user, which repos will get me the basics for watching youtube videos and listening to MP3s. Then as a new contributor that is fresh out of college/university wanting to start putting software into repos. Right now, I know there is GOOD/BAD/UGLY to get me all the stuff I need… but even then, not a lot of information is given to a new user as to why these are needed or where they can be found, you need to stumble across a walkthrough or have a friend do it.

    I know you guys deal with Linux on a daily basis, but I’m coming from a college that doesn’t promote Linux in a “real world” sense, so all software is promoted as windows only. There is no formal education on repos/RPM/DEB or how to build something in Linux. I can compile and run a c program just fine, but how do people learn how to build an RPM or how to share their programs.

    The whole thing isn’t easy for anyone to understand. From beginning to a shared program.

    I love the software center and all the wonderful things it can do, Richard and friends are doing a fantastic job, but it seems to lack in making Fedora useful for the every day user. I don’t think I know an ordinary user that doesn’t need flash installed anymore. I know you guys know this already… but it is still not point and click easy yet.

    For you to “win” users, you’re going to need some of this stupid easy stuff for people to use.

    • Unfortunately due to current US intellectual property laws, media playback is one of the most difficult areas. So we can’t do that officially.

      Building and sharing an RPM — especially with COPRs — would be a good article. That’s a great way for someone like you describe yourself (college or newly out of it, able to compile a C program without problems) to share programs with others. There’s plenty of existing documentation, but you almost need documentation to know where to even start reading. :)

  3. Hunkah

    I understand that US IP laws suck the life out of everyone, but doesn’t having a repo solve this issue? You don’t install anything yourself, so can’t be liable for it… but you have something like a repo that can simplify the process by saying “if you are in a location that blah blah blah, click here to install… blah blah blah.

    I (and a friend of mine) have been trying to get some simple walkthrough for creating an RPM for a very long time. We haven’t been able to find anything that makes the process easy to understand. I swear the more I learn the more I need to learn.

    If the college didn’t keep me so busy I would attempt to learn how to to an RPM and create a walkthrough, but it’s almost impossible right now. If no one else does it, I would be glad to.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>