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@xxxxxxxxxx> > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
