Fedora board vote and way forward

Adam Williamson awilliam at redhat.com
Fri Jan 24 18:49:35 UTC 2014


On Fri, 2014-01-24 at 13:23 -0500, Christian Schaller wrote:
> Hi Adam,
> It is not really a question of trying to be tricky here. I understand
> that us trying to find a solution both sides can live with here feels
> frustrating to you, as it constantly butts head against where you feel
> the boundary should be, but trust me the situation is frustrating for
> us too.
> 
> But I agree that a tenable solution is not likely to be found in this
> direction, so I think what we need is to take a step back and some
> timeout to try think outside the box about this problem. Your idea
> from yesterday to enable features such as this in a differently
> branded product has some obvious issues to me, but at least it was a
> good example of someone trying to come up with a solution to the
> disagreement by not getting locked into the the context of the current
> debate, and thus maybe something we should at least think about.
> Anyway maybe some brainstorming is what is needed here.

Yeah, sorry, I think I got it out of my system now. :)

I didn't really bring up differently-branded products as a concrete
suggestion for what the Fedora Desktop team should do, just as a useful
reference point for the wider debate: it's a way of reinforcing the
point that the really problematic issue here is the 'Fedora/not-Fedora'
distinction. It's absolutely fine for Korora etc to do whatever they
want because it's very clear that doesn't come with the endorsement of
the Fedora project/distribution. But I expect people who use Korora have
an explicit or implicit understanding that Korora, to some degree, is
standing behind the stuff they're including: if they install Korora and
then install a couple of updates and Flash breaks, they're going to
complain to Korora, right? They see it as a piece of Korora.

The practical suggestion I find most interesting is a
*cross-distribution* infrastructure/platform for the provision and
distribution of third-party software, quite simply. My take is that the
fact there's nothing like this that all or at least most of the major
vendors agree on is much more of a problem for both users and
distributors of third party stuff than any single distro's exact
perspective on how far it should isolate itself from third-party bits.
As we've already gone over, I don't think the degree of isolation from
third-party bits that Fedora currently insists on is so great as to form
a major barrier *in itself*.

It's also worth noting that Chrome/Flash etc and NVIDIA are kind of
different problems. NVIDIA is a very tricky case much more because of
the technical details of that particular case than just because it's
third party software. I haven't really seen anyone who had much of a
problem with the *theory* of how to install NVIDIA, which is more or
less 'enable the magic repo and then install a couple of packages'. The
problems people have in that case really are technical implementation
issues: specifically, getting nouveau out of the way of nvidia is kind
of tricky and the details seem to change from release to release, and
then Fedora is rather ahead of NVIDIA in its kernel schedule - so quite
often we bump a stable Fedora release to a kernel version which NVIDIA
isn't ready for yet, so even if you have the akmod for NVIDIA rather
than the kmod installed, everything goes sideways.

My point there is that we should probably think harder about the
Chrome/Flash/whatever case - the case of things that are basically
'apps' sitting quite lightly on top of the distribution 'platform' -
than the tricky NVIDIA case, which is kind of a special one and requires
special handling. For the 'app' case, I really think that having a
*single* distribution platform for all the major distros would make
everyone's life a lot easier, and would not be hard at all to reconcile
with Fedora's fundamental principles - we just have to isolate access to
that platform to whatever degree is agreed to meet our principles, and I
think we're all agreed that that degree doesn't need to be *excessively*
onerous, just enough to keep Fedora's principles clear and the
separation of responsibility clear.

Of course, this requires both building the infrastructure/framework and
the distributions committing to *some* kind of platform that the third
party distributors can rely on - even if it's as basic as 'we'll give
you glibc and an input layer and ALSA/PulseAudio and maybe we'll commit
to a couple of toolkits being available, anything else you can bundle
yourself or manage the cross-distro compatibility some other way'. But,
at least IMHO, that's the approach that provides the best payback. It's
already what happens, in effect - most third party distributors don't
build tweaked and tested packages for all distros, they just build a
huge static bundle on top of glibc and ship it in a tarball (or a 'dumb'
RPM/DEB package which doesn't really use any distro dependencies, it's
just being used as a container). But we don't have a nice neat
distribution platform for their tarballs/dumb RPM or DEB packages, so
users have to go out and find them in a dozen different locations, and
there's lots of silliness in how they work probably because all the
distros aren't getting together and providing some simple groundwork and
rules.

If we just had a nice Software/Steam-ish platform where you'd know all
the major third-party stuff was available, with a decent interface and
screenshots and reviews and all that gumph that's the current vogue,
it'd be a much nicer experience, even if ultimately what you got was the
same big static bundle you get from a tarball/dumb package today.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net



More information about the desktop mailing list