App duplication again (Re: new project in kdemultimedia)

[Andreas Pour]

Klas Kalass wrote:

> > I don't believe in the whole notion of "core" packages. IMO the only core
> > that we have is kdelibs (for apps/developers) and kdebase (basic runtime
> > environment) and everything else is "apps" in my book.
> 
> The Announcements for the releases (like KDE 3.0) always mention programs of
> the other packages. So it looks to the reader as if all of this was "the
> KDE". If we do not want that we should release all of those packages
> seperately and only kdelibs/kdebase as the parts making up a KDE release. In
> that case we can say "those are just programs put together in one place for
> convenience of the developers" and not mention any programs that do not
> belong to libs/base in the Release Announcement. But if we leave it as it is
> I think that we should take all packages as serious as kdelibs/kdebase and
> make sure it is "round" and "well put together". It looks like a "KDE
> Distribution" now and we should treat it like this or change what we
> communicate as being KDE to the outside.

Hi,

That's the general problem with the "no packages" approach, it has not
been thought through.  There are a number of issues which arise.  This
centers around the question, what is the point and consequence of having
something in KDE CVS?

Historically the significant of being in KDE CVS (kdenonbeta aside) has
been:

 (1) something the translation team works on
 (2) something the documentation team works on
 (3) something the artist teams work on
 (4) something the marketing teams work on
 (5) something the distributions package
 [(6) something that users can roughly assume other users will also have
installed]

All of this is just a general outcome of the fact that KDE is a group
project, and what the group works on is what is in CVS (excepting
kdenonbeta).

Now if this methodology is to change, we need answers to what it is each
of these groups works on.  The thing I have found fundamentally
troubling about the discussion to this point is that it has ignored
these issues. 

It doesn't make sense to change a (relatively) well-functioning system
without any real thought about the dynamics of how it would work, the
problems that might arise, the effect on group dynamics and the
cohesiveness of the KDE team, and the improvements which are expected.

So if there is a serious proposal for a change, I would at least like to
know:

 (A) what will be the point of having code in KDE CVS, as opposed to,
say, sourceforge or berlios?
 (B) what is the advantage of breaking the team approach in favor of a
developer-centric approach?
 (C) what are the weaknesses in the current system that mandate a
change, and how does the proposed change improve on them?
 (D) what are the strengths of the current system, and how does the
proposed change weaken them?

And there will be more issues to address, but this is a sensible start.

AFAICT, the only reason to change from the current system is that some
people don't want to exercise the responsibility of deciding what should
be part of the "Team Project" (i.e., in KDE CVS), and what should not. 
I think this issue can be dealt with a lot easier than all the other
issues what will arise if the system is changed.

Actually, I think the current system is a very good one (except it
should be trivial to split packages apart to package the apps
separately), and I think KDE's success is largely due to the
team-oriented organization of the project.  I really think we need to be
very careful about changing things on a whim.

Ciao,

Dre

-- 
None are more hopelessly enslaved than those who falsely
believe they are free.
  -- Johann Wolfgang von Goethe