Toshio Kuratomi (a.badger@gmail.com) said:
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."
... and the people who chose the net install get what, exactly?
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.
Sure, and then if you run a GNOME app on KDE, you get what, exactly? If you have a non-GNOME, non-KDE app, which do you choose to support? By letting each desktop choose their own environment, you make things worse for anyone that has to support both.
Bill