What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Miloslav Trmač]

2014-03-21 14:46 GMT+01:00 Dennis Jacobfeuerborn <dennisml at conversis.de>:

> As I perceive it one of the biggest problems for Fedora as a development
> platform for new technologies is that everything is tied to very rigorous
> guidelines and controls that tend to be fairly conservative. This is great
> when you care about overall stability and coherence of the platform but
> terrible if you want to enable people to use Fedora as a platform to
> spearhead new technologies.
>
> One example is the policy that patches for packages should first be
> submitted and accepted upstream before they make it into Fedora. This works
> great because that way you can ensure that once features are added in
> Fedora it is unlikely that they have to be removed later again because they
> are rejected upstream. It's terrible though if you want to live on the
> bleeding edge. Take for example the networking features of OpenStack that
> required kernel changes that weren't yet committed upstream or the fact
> that Docker required AUFS for a long time. In both cases Fedora was a
> terrible platform to develop these technologies because of its conservative
> stance.
>

Well, a distribution is an *integration* project.  Everyone is perfectly
free to replace individual components with HEAD checkouts, or the
equivalent copr RPMs, to be able to develop such bleeding-edge software;
but that doesn't automatically mean that the millions of Fedora users
should have the same bleeding-edge software imposed on them just so that
the developers of that specific project have an easier time.

For users, Fedora really should include and promote software that is
*past*the bleeding-edge state, something that we can honestly
recommend to the
end-users as safe and practical to use.  That does tend to rule out major
out-of-tree patches, especially for kernel, and especially especially for
union filesystems, which have a multi-decade history of being created
out-of-tree and never becoming good enough to include in the mainline.

For developers, the current work of enabling copr and other related
activities should make the developers' life easier without impacting the
end users.

That said, I do think we should not be hostile to small Fedora-specific
patches that include the *integration* of the distribution.


What I hope will happen with the "Productization" of Fedora is that these
> products will be allowed to have a more independent identity and given more
> leeway to do things different. I will go so far and hope that eventually
> these products will be allowed to have their own policies regarding
> packaging and for example be able to ship their own kernel packages likely
> to be derived from the main kernel but with additional patches as the ones
> mentioned above.
>

So far FESCo has had a fairly strong consensus on minimizing the
differences within packages between Products--it's fine for the Products to
differ in package selection, but differences in package content, while
probably inevitable, should be minimized.


> Anyway my point is that telling product A that they cannot proceed with
> their work until product B is released is pretty much the opposite of what
> you want to do.
>

That's not the F21 situation: what has been considered is that no new
products (not targeted at any particular one) could proceed until we know
that the infrastructure for *all* projects is workable (with the current
three products serving as guinea pigs, thinking that we do need
*some*guinea pigs but having more is not useful).


> Instead the message should be: "Want to create a new way to manage the
> update life-cycle of systems (OSTree)? Want to create a new way to manage
> better application deployment (Docker)? Build a Fedora product as Fedora
> can provide you with a solid foundation for whatever you are trying to
> accomplish!"
>

Well, the Fedora Products do need t*o still be Fedora*.  We shouldn't end
up in the other extreme position of Fedora providing hosting to dozens of
software distribution projects that have nothing in common, and there is a
definite balance to be struck.  To me, a significant factor in the balance
is "does the subproject benefit from, and is it beneficial to, the work of
the thousands of Fedora contributors not working on that subproject?",
which would rule out single Products unilaterally moving away from RPM and
ignoring the bugfixing and patching done by Fedora contributors on the
RPMs, for example.
     Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140322/858b00fe/attachment.html>