F21 Self Contained Change: Playground repository

Christian Schaller cschalle at redhat.com
Wed Apr 9 07:16:09 UTC 2014


To chime in here, we have been doing something like this in 
GStreamer for a long while. There is 'plugins-base' and 'plugins-good' 
plugins which is comparable to the current core Fedora repository.
Any plugin going into base or good need to conform to certain
coding standards, licensing standards and documentation standards.

Then there is 'plugins-ugly' which is more like rpmfusion. It still 
has the coding and documentation standards, but licensing can be 
of a wider variety. (Not just 'non-free' as GStreamer do not accept 
GPL plugins into the base or good repositories either due to being a 
LGPL toolkit).

Finally there is plugins-bad, which is a bit more like what I think 
Playground will be. It is a repository with plugins which for a variety 
of reasons are not ready for any of the other ones yet. This could be 
that they are not of a high enough coding quality yet or lack documentation, 
but they still 'work'. And what we found over the years, is that while 
it is good to have high standards for these plugins to stretch towards 
in order to get included in one of the other modules, having 'bad' 
available is crucial as a way to get access to plugins that might be 
critical to their usecase even if they are not up to our technical
standards yet. So while it can be frustrating that some plugins end 
up lingering in bad for a long time, it is still a much better scenario 
than people deciding GStreamer is useless for them and move somewhere else.

Christian



----- Original Message -----
> From: "Stephen Gallagher" <sgallagh at redhat.com>
> To: devel at lists.fedoraproject.org
> Sent: Tuesday, April 8, 2014 7:04:54 PM
> Subject: Re: F21 Self Contained Change: Playground repository
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 04/08/2014 12:24 PM, Michael Cronenworth wrote:
> > Jaroslav Reznik wrote:
> >> For now the Playground repository contains both packages that are
> >> destined for eventual inclusion into the main Fedora repository
> >> and *packages that are never going to make it there.*
> > 
> > This sounds like a problem and not a feature. Why would packages
> > never make it to Fedora, yet be available in this new repository?
> > 
> > My intent here is to be constructive so my question is genuine. I
> > don't believe Fedora should start down the path of a fragmented
> > repository structure. It makes sense for RHEL and its software
> > channels it can sell support for, but Fedora is different.
> > RPMFusion being an exception as it is a legal necessity.
> 
> My interpretation here is that there exists plenty of genuinely
> open-source software out there for which it will likely never be
> possible to package fully according to Fedora's packaging guidelines
> due to bundling or similar issues (the obvious example being the
> oft-requested Chromium).
> 
> Similarly, there are a great many useful Ruby libraries and
> applications out there for which unbundling them would be an exercise
> in futility. Ask yourself which is more important to most users:
> 1) My OS is perfectly maintainable by engineers.
> or
> 2) My OS lets me install the software I need without hassle.
> 
> Offering users a slightly-less stringent repository such as this makes
> sense.
> 
> Also "packages that are never going to make it there" should probably
> have been phrased more politically: "Even if the reality of the
> situation is that perfect adherence to the Fedora packaging guidelines
> is infeasible".
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iEYEARECAAYFAlNELDYACgkQeiVVYja6o6MoCACggkj5lqoAtzbDxboz94/bxXma
> wH4AoI33Q7n/z2W+q6+9baU1ohhR7iXg
> =IzBI
> -----END PGP SIGNATURE-----
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


More information about the devel mailing list