App duplication again (Re: new project in kdemultimedia)
Michael Matz
matz at kde.org
Tue May 7 11:00:41 BST 2002
Hi,
On Tue, 7 May 2002, Stephan Kulow wrote:
> > Gnome is more or less following this principle (e.g. a Gnome "release" is
> > actually a snapshot of all apps at a given point). It's a freakin' mess.
> > The big problem is that there's no incentive for maintainers to stabilise
> > their apps at some common point. Plus there's the fact that packaging
> > requirements go through the roof (each app has to be packaged seperately).
> I don't like the idea either. We should open another module, where we add
> activly maintained applications, that can be released seperatly, but that do
> not are active part of the KDE release. But we should definitly keep e.g.
> korganizer and kmail in freeze together with kdebase.
Something like this yes. But this can also be reached by making a list of
what constitutes the next KDE release, which is a subset of things in CVS.
Translators, doc writers and such would concentrate on them, and it would
be made sure, that there not too much duplication in that list. That it,
I don't see the big difference in having everything minus "that module" in
the list. We can split the list (i.e. KDE) over all the modules.
The only problem I see is, how to work out that list. I mean, there sure
are undisputable things like kmail, korganizer or basically everything
which isn't duplicated, if it's stable enough. The problems arise when
there _are_ programs with similar functionality. I'm not sure either way
would really solve this. I would use a first come, first included way,
probably include a second one, if it differs enough, and replace that set
only, if one of the other alternatives are obviously superior in the
opinion of more than a few people.
That said, it also makes no difference to implement that list as CVS
modules. We can create for each module x a module x-some-suffix. It
would include a superset of what x contains. x would be the next release,
and x-some-suffix a dumping ground. On the server side, this would be
implemented with soft-links, much the same as the admin directory.
Ciao,
Michael.
More information about the kde-core-devel
mailing list