Happy New Year everyone! And also, congratulations on and thank you for a
really excellent Fedora 20 release. I've seen and heard a lot of positive
feedback and I'm quite confident in telling people that this incarnation is
the best Fedora yet.
But, of course, nothing stays still, and there's no better time than now to
talk about where we're going next. I've been thinking about this a lot
(because it's always been interesting to me, and, full disclosure here, it
doesn't hurt that Red Hat is paying me to think about it). So, following are
three big themes which I think are important to Fedora in the coming year,
and I hope I can get you excited about them too (if you're not already). I'd
very much also like to hear your thoughts. The idea is to integrate
everyone's expertise into something which approaches a coherent plan.
1. Virtual Flock
Fedora has a great community, but we have no visible center (except maybe
this mailing list). We have a number of other lists and other loosely-linked
online presences -- IRC, the wiki, all our various web applications like Ask
Fedora and Badges, and external groups like Facebook and Google+, Some of
these function well and have strong, positive culture, others have various
degrees of dysfunction, and others just aren't working at all.
When I go to a Fedora conference -- FUDCon, Flock, whatever we call it -- I
always come away feeling energized and optimistic and just generally
enthused with how awesome the Fedora community is. I want that all the time.
But, it seems like it kind of all drains out until the next big recharge of
seeing everyone in person.
Since we can't afford a monthly conference (ha!), I want something that
feels like it online. A hub for the community, where we have that
interconnectedness all the time. I think this centers around HyperKitty --
which should be ready for production any time now. Let's make that
front-and-center when answering the question "what is Fedora?", and tie it
to Badges, Fedora Magazine, Ask Fedora (possibly have it _replace_ Ask
Fedora), and a new solution for short, helpful howto-style content (an
element we're sorely missing now).
2. Focus and Flexibility
Stephen Gallagher's "Three Fedora Products" proposal is well underway right
now, with exciting progress -- I think that's been visible enough that
there's no point an extensive review here. The working groups for these
products are producing planning documents right now, and we'll develop an
overall plan for the F21 release based on those.
The idea of the there products is to focus on making specific things that
people can look at and say "okay, I know what that's for". This is great,
and I strongly believe that it will help us grow Fedora in our second
decade. But, it also can't be a reduction of what Fedora is.
We also still need the general Fedora collection, because a large but
carefully curated collection of open source software is one of our greatest
strengths. Last summer I suggested calling this Fedora Commons and
immediately discovered that that's taken by the unrelated other Fedora
[document] Repository software.... we need a different but descriptive name.
Maybe it's "Fedora Collection".
At the same time, we need to be more flexible around the edges -- from my
Flock proposal, "Ring 2", with software collections and Ruby gems and Python
eggs and containers and whatever else, even if it hasn't yet been perfected.
This is the area of the Environments and Stacks Working Group. I think it's
likely that in order to explore this, we'll want to create a new Fedora
repository separate from the "Fedora Collection" but still under our main
umbrella. We have one such thing already -- EPEL. This would be similar in
concept, but of course with a different set of guidelines. (It might target
both Fedora and EL+EPEL, and have a different sort of lifecycle from
either. In any case, details to be worked out.)
When I talk to people at tech meetups and at startup companies, a basic core
plus a selection of software stacks is _really_ the area that they're
interested in, and I get the feedback that no Linux distro really does this
well. Let's be the one that does!
3. Continuous Delivery
Here's the vision: For every code or configuration change which affects one
of the Fedora products, a shippable version of that product is generated.
That doesn't mean that we have a rolling release -- or even that we force
every change to be compliant -- but that when a change occurs, there should
be an automatic feedback loop which lets us know if that change integrates
as expected. This will move overall testing from being a last-minute
scramble to something that we can watch all along the course of a release,
and free up priceless human tester time for the places where intelligence is
really useful. And, it will make it easier to build a larger community of
users -- and developers -- who are tracking the bleeding edge by running
Rawhide or development releases.
We're a long way off: right now, we produce potentially-shippable artifacts
as part of the alpha, beta, and release candidates of Fedora, in an
excruciatingly painful manual process, and then we test those things after
the fact, again by hand. We also tend to land changes in a big, irrevocable
way rather than using software design patterns like feature switches.
Getting to the ideal statement seems scary and big, but the product focus
helps because we don't have to worry about getting every little package
perfect. We just have to change how we're doing.... almost everything. We
have a ton of smart people -- let's get agreement that this is a valuable
goal and get to solving it.
So those are my things. What do you think about them? What else should be
included? What different directions should we consider? How will we make
Fedora more awesome than ever in the coming year?
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
While translating some of the fedora packages we often come across some
source strings whose context or meaning is not clear. This results in
wrong translations which is discovered later while using the actual
application. This in turn effects the concerned application.
To solve this issue, we have formed a Fedora SIG named "Source String
Contextualizing Group"  aimed at
providing concise yet meaningful description of the concerned source
strings in the source code itself to ensure the correctness and quality
in the resulting translations.
We welcome feedback and suggestions.
I've switched to rawhide yesterday, and discovered that vinagre now
forces rsyslog onto my system. That's not great.
The dependency chain goes something like this:
vinagre -> spice -> libcacard -> ... glusterfs ... ->
rsyslog-mmjsonparse -> rsyslog
I think there's at least two questionable links in this chain:
- why does libcacard need glusterfs ?
- why does glusterfs need rsyslog ?
Can we get one or both of these cut, maybe ?
I'm going to build a new PackageKit snapshot into rawhide this
afternoon which will include a soname bump to libpackagekit-glib. All
the upstreams now do the right thing with #ifdefs (the new version has
been in jhbuild for a few months) and just need rebuilding. I'll take
care of the GNOME deps as well.
----- Original Message -----
> From: "inode0" <inode0(a)gmail.com>
> To: "Development discussions related to Fedora" <devel(a)lists.fedoraproject.org>
> Sent: Thursday, January 30, 2014 8:01:15 AM
> Subject: Re: Fedora.NEXT Products and the fate of Spins
> I guess I'd like those active in the spin community to make
> suggestions here. I imagine spins and other new creations built on
> Fedora to be things the project wants to promote, not push away. The
> reality may be that we can't do what we do now in support of spins,
> but I hope we can continue to do something that helps and encourages
> those making them.
I am the maintainer of the Fedora Scientific Spin and I speak wearing my Fedora community
member hat (not RH employee).
A bit of background will put things into better perspective. The Fedora Scientific Spin
was first released during the Fedora 16 release cycle. I failed to fix a build failure
due to package dep. issues during the F19 release cycle, so, we have had 4 releases since then.
I haven't been bombarded with emails from users, but I have had emails from users who find it
useful and have requested for things to be included (which couldn't be included for other reasons).
One good thing to come out of the failed F19 release was that I came to know that people do care
about Fedora Scientific, since I had potential users looking to download it, but didn't find an ISO.
Now, I will begin the pitch for Fedora Scientific to exist. I think Fedora Scientific is a good thing to have
in the Open Source scientific computing ecosystem. Thanks to the packagers, we have all the tools/libraries that
the ecosystem boasts of ready to use in Fedora Scientific . We may be even attracting users to Fedora due to it
(no facts to back it up), since the closest distro that aims to achieve what Fedora Scientific does is
Some more points re. specific issues pointed out and what can be done about it:
- Starting with Fedora 20, all the spin maintainers were supposed to fill a matrix
(as someone else already pointed out) which was a validation that the test composes,
the RCs, alphas and the betas worked correctly (installation, applications packaged,
etc.). Overall I think it was a good thing to have as it helped the spin maintainers
to fix issues with their builds. So, +1 to that and we should continue it. 
- I am not exactly sure about the cost of doing the builds, checking why they may have failed, etc.
So, perhaps, this can be something that my be off-shored to the spin maintainers? It increases
our responsibilities, but helps lighten the load from rel-eng.
- In my moment of "Is Fedora Scientific actually being used?" or, more recently, "Is it even a contribution worth a Fedora
10-year anniversary T-shirt?", I have thought that perhaps, all the packages that Fedora Scientific ships
can all be made into a yum group and the user can just do "yum groupinstall fedora-scientific". Yeah, perhaps
it can be done, but I hope we don't have to, since it still needs the user to download a whole bunch of stuff
after the install, the exact problem I wanted to solve using Fedora Scientific.
Overall, I think Fedora Spins are a good thing to have, and we must address the question of how we can keep them
by sharing the work that goes into having them, rather than eliminating them or converting them into Remixes.
 http://fedora-scientific.readthedocs.org/en/latest/ (Needs a lot more work to make it complete)
Amit Saha <http://echorand.me>