RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Miloslav Trmač]

Hello,
(more technical / process questions below; high-level comments will be
sent separately.)

On Mon, Jul 22, 2013 at 3:38 PM, Matthew Miller
<mattdm at fedoraproject.org> wrote:
> Whenever I go to a tech meetup or talk to someone from a new startup
> company, their developers are inevitably using a different (usually
> proprietary) desktop OS, plus a non-Fedora distribution on their code. We're
> being left behind and left out. It doesn't matter how theoretically great we
> are if we end up with no users.

How does the proposal actually improve this?  Giving various SIGs more
freedom to manage various stacks makes neither the core nor the stacks
automatically any more attractive to anyone.  (Even allowing stacks to
evolve separately from the core and more in tune with upstream
releases doesn't make the Fedora version of the stack automatically
any more attractive than just installing the upstream version in the
way upstream documents.)


>   Stacks
>   ---
>   * Languages, databases, libraries
>   * Maybe X/Wayland
>   * The kind of things which could be OpenShift Cartridges or Software
>    Collections

>   Possible Examples
>   ---
>   * Can override versions of software at lower tier
>   * Can overlap with software from other stacks
>   * Not necessarily even RPM
>   * Different lifecycle (but shared release cadence)

How do I package and ship an application that depends on two or more
stacks (e.g. uses a database, has a web frontend and perhaps also a
local GUI) if the stacks the application depends on can have
overlapping and therefore probably (necessarily?) conflicting
software, different lifecycles and packaging methods?

>   Fedora Commons
>   ---
>   * The collection of packages outside Core following traditional policies
>     and practices
>   * We're not throwing that away
>   * Many people continue to be interested in this model
>   * Shared by other parts of Ring 2 where possible
>
> This is a special bubble within Ring 2. In fact, on Day 0, it still is _all
> of_ Ring 2. The name here is mean to evoke Creative Commons; we can discuss
> other possibilities too, of course.

What happens when a RPM (presumably) package from Fedora Commons
depends on infrastructure that decides to move to a stack and stop
using RPM?


> In the future, a namespace approach
> could even make /usr/bin/python be Python 3 for some processes but not for
> the core OS.
(Namespaces are an administration nightmare because paths suddenly
don't mean what they seem to mean.)
    Mirek