Board efforts: scope, concept, and permission?

[Bill Nottingham]

Adam Miller (maxamillion at fedoraproject.org) said: 
> > 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.
> 
> I think the responsibility of these things should be placed upon the
> SIG members who perform the functions from within these different
> groups. Why not have a QA person from each SIG work together with the
> larger QA efforts instead of potentially against them?

Take a random downstream app. (Firefox is an example, but there are many
others.) Right now, it only needs to track a single version of python,
or a single auth framework, even if it may be used on any desktop or any
spin. The implication is that in some sort of future with SIG-specific
conflicting frameworks, this downstream app maintainer now must be familiar
with, and handle *all* of the frameworks, even though they're not
specifcally a part of any SIG. That's sort of a rotten thing to do to
Joe Random Maintainer. 

You could say that the SIG needs to then supply people to handle every
potential downstream app, but that's also not nice, and is going to lead
to fun coordination with updates.

Bill