Fedora.next in 2013 -- Big Picture and Themes

Haïkel Guémar hguemar at fedoraproject.org
Fri Jan 3 20:44:17 UTC 2014


Le 03/01/2014 19:14, Matthew Miller a écrit :
> 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.

Happy new year to you ! :o)

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

Are we still bickering about who is paid by whom ? ;)
As long as decision is backed by the *Fedora Community*, anything else 
does not matter.

> 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).
We did virtual FUDCon in the past, great experiences but it's not 
possible to run it monthly too.
As for howto-style content, i suggest that either we cooperate more 
tightly with local communities which most of the time, already manage 
such contents (in a more flexible way), or we lower our expectations 
given that howto have a shorter lifespan than content managed by the 
docs team.

My opinion is that we need to reorganize the whole community management 
sub-projects (ambassadors, marketing, ask fedora etc.) into something 
like "Community Herders".
Community herders will handle
1. marketing (press releases, events, etc.)
2. generate and maintain content (howto, magazine, forums, etc.)
3. act an effective stakeholders proxy in other sub-projects (packaging, 
SIG etc.)

Pros:
1. simplify the community management
2. less dissonances in our communication
3. voicing our community inside Fedora
4. get rid of the funny titles (i won't say anything more but it ended 
up being a PITA)
Cons:
1. more stuff to manage, more coordination ?


>
> 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.
+1

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

Basically, Fedora Core is (and is not) back ;)

> 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!
>

+1, i've heard pretty much the same thing. There's even a room for paid 
support but that would be outside fp.o scope.

> 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.
Ambitious goal which requires having effectively rings but also better 
tooling (rel-eng needs help to script and automate stuff !), better QA 
(the same goes for auto-QA and moaarrr testers !)


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

One of my concerns is about bringing fresh blood into the project, it 
means: lowering the entry level without compromising with the usual 
fedora quality, more mentoring etc.
Why not a Fedora Contributor Outreach program led by the Community 
Herders ? ;)


Best regards,
H.



More information about the devel mailing list