Adam Miller (maxamillion@xxxxxxxxxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
