On Tue, Feb 02, 2010 at 03:17:30PM -0500, Bill Nottingham wrote: > Toshio Kuratomi (a.badger@xxxxxxxxx) said: > > My other mail suggests that one way to work with this is to create new > > conflicting packages that are optimized for the different usages. There's > > other ways as well but the general theme is that we need to be looking at > > ways to open up what people can do with the raw material of the Fedora > > Project to create their vision of a free software operating system rather > > than closing off what Fedora can be good for and making it so that certain > > visions are second class citizens that can only advance as long as they > > don't conflict with a different, specific vision. > > Would that mean that users who don't start with one of these 'products' > get to magically try and choose which implementation of which they want? > Perhaps even mix and match, leaving QA and the developers to sort out > the results. > Nope. Users get a Product. That product has made choices about what packageset they receive. Mixing and matching of implementations is done at the level before the end-user. The Project can find ways to make this saner without going all the way to "if you conflict with the target audience your vision is not valuable here." > Furthermore, you then leave 'downstream' higher-level packages and > applications having to, for example, code to PolicyKit0, PolicyKit1, or > consolehelper, depending on what each 'product' use case might use. Or, > having to build their python extensions simultaneously for python2.4, python2.6, > and python3.0. These sorts of things would be extremely painful for > developers, and would bloat the QA matrix excessively. > Also no. You think that you can make people work on things they don't have an interest in? I certainly don't. Let's look at PolicyKit0 and PolicyKit1. KDE has one or two apps that uses PolicyKit0, Gnome has many apps that use PolicyKit1. People concerned with Gnome are packaging PolicyKit1. KDE SIG volunteers to package PolicyKit0 for their apps' consumption. Do the gnome apps have to support building with PolicyKit0? no. Do the KDE apps have to support building with PolicyKit1? no. You have people doing the work they need to in order to realize their vision. For Fedora 13 we are going to be supporting both one python-2.x and python-3.x release. People who care about the respective stacks are going to start building extensions simultaneously for both. People who care about it are doing the work to see their vision fulfilled. OTOH, there aren't people who care about launching a similar effort to build and package for python-1.x (or even 2.4 unless you count EPEL). No work is being done there -- and no one is wasting their time doing it. If there's a need, people will do the work to support their needs. If there's no need, nobody will. The job of Fedora's Leaders is to balance the individual needs of people who are working to create, sometimes conflicting visions, with the needs of each of those visions to get along in the same playground. Rather than classifying some of the kids as second class and siding against them when there's a dispute, it's better to find ways of expanding the playground to give more people the opportunity to form communities working on what they want. > Not to reduce the debate to too much of a soundbite, but it almost > seems like attempting to decide whether we want Fedora to be Debian, > or to be something useful for users of it. I'd always pick the latter... > The problem with this sound bite is that Fedora Project and Fedora product get mixed up. Users use a Fedora product. The Fedora Project attracts the contributors who make various Fedora products. You can't continue to be an attractive place for people wanting to experiment with creating different visions that don't necessarily appeal to the target audience if they're always going to be a second class citizen. -Toshio
Attachment:
pgpAH493EFzdx.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
