* Lubos Lunak
- some people taking part in the discussion do not understand some, even basic, things about the strategy discussion, such as the purpose - the strategies either fail or very poorly state some practical aspects (most notably an answer to the question 'why should we do this?') and feel more like something abstract that should be discussed over coffee
I'd be temptetd to say that you can't blame them considering how this discussion has been initiated, i.e. starting with some highly specific proposals before even determining the status quo and then discussing what is wrong with it and whether something and if so what should be changed.
Why we need a strategy: ================
And since everybody gets things better when there's an example, let's have one hypothetical case. Assume that in time for openSUSE 11.4 the latest Firefox release will be 4.0.1, which will support some latest Web technologies, but will not be as tested as Firefox 3.x and its KDE integration will not be ready. The maintainer therefore will need to choose one version as the shipped default, and there wil be trade-offs. 4.0 would be presumably preferred by most Web developers and bleeding-edge users, 3.x would be preferred by "stable" users and KDE users. For simplicity let's also assume that installing both 3.x and 4.0 at the same time is practically impossible because of not having enough contributors for solving the necessary problems.
Currently it's more or less at the judgement of the maintainer of the component. This can lead to various problems such as the decision not being good for the majority (e.g. if the maintainer is a GNOME user who likes new Web technologies but the majority are users who use KDE and/or want a really stable browser) or leading to inconsistencies (a maintainer of a different component related to Web decides not to enable an experimental library for new Web technologies, making openSUSE not either for stable users or for Web developers).
With a strategy, this is much simpler. KDE #1 strategy, productive poweruser strategy will most probably favour 3.x, while home for developers strategy and mobile/cloud strategy will presumably favour 4.0. Either way, it will also cause the other maintainer to not enable or enable the experimental library accordingly.
We already have a strategy, before this discussion it had not been written down (and it would even provide an answer to your example). Whether it is inadequate and we a different strategy is another issue.
Things a strategy does not change: =======================
I hope the example makes some things about strategies rather clear:
- selecting a focus does not make other areas forbidden. The case above does not stop anybody from maintaining packages of Chromium or Arora. There are examples of e.g. KDE being provided as Ubuntu or Fedora spins even though they are not the focus. In fact, with the build service, unless openSUSE would decide to actively block some contributors (which would be pretty stupid), the only reason for a component not being anymore available for openSUSE would be its contributors deciding so.
The proposals are pretty exclusionary so far, e.g. they propose removing packages from the core distribution. Putting the motivation of contributors working on thing which are not a focus any more aside, this is also a matter of integration, increasing fragmentation will make that increasingly difficult.
- contributors can focus on whatever they want and cannot be forced to switch. With a community distribution this just plain doesn't make sense. In the example, the "perfect" solutions would be making Firefox 3.x and 4.0 co-installable or fixing the problems, but if people will be interested in other areas and there won't be enough contributors to make these happen, they simply won't happen. How can somebody be forced to voluntarily work on something specific?
- strategies cannot be just team strategies. For example, the KDE #1 strategy already is openSUSE KDE team's strategy, but there are problems that reach beyong the team. In the example above, with the Firefox maintainer's decision to go with 4.0, KDE in openSUSE obviously suffers and this is out of control of the KDE team. It is obvious that openSUSE not preferring a desktop cannot provide as good KDE implementation as it could with focusing on KDE as the primary desktop. This applies generally, in some cases making something better inevitably leads to something else getting worse in the real world.
By implication this means that such decisions will always go to the expense of the "non-focus" teams as it's not a level playing field any more. Kubuntu is a prime example for the effect of a "non-focus" spinoff suffering from a lack of quality, integration and contributors stuck in a vicious circle. There is much to loose. IMHO this is a matter of teams coordinating and deliberating such issues and ultimately coming to a compromise, occasionally that produces some flamefeasts (like the KDE default debate) but that does happen in other projects as well. Narrowly focused strategies are not a magic bullet to cure that. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org