Mailinglist Archive: opensuse-project (349 mails)

< Previous Next >
Re: [opensuse-project] Problems with strategy discussions
  • From: Guido Berhoerster <gber@xxxxxxxxxxxx>
  • Date: Thu, 5 Aug 2010 20:05:24 +0200
  • Message-id: <20100805180524.GA2936@xxxxxxxxxxxxxxxxxx>
* Lubos Lunak <l.lunak@xxxxxxx> [2010-08-05 18:09]:
- 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
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

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
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

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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups