[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: why is there so little KDE PR ?
From:       Michael Matz <matz () ifh ! de>
Date:       2001-01-19 3:37:11
[Download RAW message or body]

Hi,

On Thu, 18 Jan 2001, Andreas Pour wrote:

> I agree that debating the value of PR is probably off-topic, but the
> precise issue being discussed is how packages are to be
> packaged/released.

That _was_ the issue on this thread. I reacted on the other
mails.  Packaging is on topic, and as it involves technical and PR work,
this is a good place to discuss it, but it's not for purely PR discussions
(on which I'm fully of your opinion, that people disliking PR just for
disliking, or having no idea about PR should shut up).

OK, to may be also make a point on packaging, and not just complaining:

Correct is, margeting-wise it would be better to release more smaller
things.  Also correct is, that result-oriented it's better to release one
large monolith (tighter integration, so it's more likely to run smooth).
Obviously there is a unresolvable conflict (I'm exaggerating).

Both extremes have also it's technical problems: too fat block are
inflexible, too many small blocks die the entropy death. So we met in the
middle and resolve the above conflict as much as we can, and at the same
time minimize the latter problem.  What remains, is the definition of
"middle".

Although I'm now awake since 57 hours (which for me is a record, I think),
I try to explain my thought model of KDE and its connection with
packaging: KDE is an onion with cuts toward the center. Each piece of it
represents a "component". Components on the outer spheres are more apart
from each other, than inner ones (this models the specialisation of the
components, and that more special ones are more discret. E.g: take two
basic program most users need, e.g. kmail and knode, which are on one
sphere, and two other more special programs, like e.g. a cad-program and
an IDE, which are one an outer sphere, and are more apart) Now this also
gives rise to a scheme for making releases. You can easily change outer
pieces, without affecting the inner ones. With some difficulties you can
also change more inner ones, because there is space between the above
pieces through which you can operate. The more inner a piece is, the more
difficult it is to change without affecting outer layers. The more inner a
component is, the more it constitutes the E in KDE. Components in the
outer layers do not constitute the environment but are (merely
randomly) using the same inner part.

This all is very trivial, so I won't go any further (although also other
facts of releasing can be demonstrated with this model, e.g. a package of
similar programs (kdegames) is one sphere sector; releasing only one
program of it "ripples" the surface, because it's level slightly changes,
releasing all together make the surface smooth).  All in all, the result
is, that, the more a program is special, the less it belongs to the
environment, and can be released at will, even it alone, and the more
common a component is, the more it constitutes the environment, the more
it should be grouped with similar pieces, released the same time (to make
the ground for the upper levels smooth) and with an eye on the upper
levels (if they need a change too).  A X.0 release corresponds to a
release of the inner levels, which can't be changed without the outer
ones, so this is seldom and in one big shot.

Not surprisingly this is, what we also want to do in KDE in the future.
kdelibs/base being the two innermost level, then probably kdenetwork and
kdegraphics. The subparts of the latter two begin to be able to be
released independently, though they shouldn't without good reasons, as
they still constitute the core environment.

Hmm. And now I send this half-finished trivial pamphlet to kde-core. Silly
me. But I can harldy think anymore ;)


Ciao,
Michael.

[prev in list] [next in list] [prev in thread] [next in thread]