Board efforts: scope, concept, and permission?

[Toshio Kuratomi]

On Tue, Feb 02, 2010 at 03:17:30PM -0500, Bill Nottingham wrote:
> Toshio Kuratomi (a.badger at gmail.com) 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100202/c579450c/attachment.bin