From kde-core-devel Tue May 07 15:49:37 2002 From: Klas Kalass Date: Tue, 07 May 2002 15:49:37 +0000 To: kde-core-devel Subject: Re: App duplication again (Re: new project in kdemultimedia) X-MARC-Message: https://marc.info/?l=kde-core-devel&m=102084593614486 Am Dienstag, 7. Mai 2002 11:46 schrieb Stephan Kulow: > On Tuesday 07 May 2002 00:55, Guillaume Laurent wrote: > > On Monday 06 May 2002 22:47, Waldo Bastian wrote: > > > I support that. I am not opposed to the idea of releasing KDE 3.1 a= s > > > just kdelibs and kdebase and all the other packages could be releas= ed > > > independently (ether as one big packages or on an app by app basis)= and > > > possibly on different schedules. > > > > 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' me= ss. > > The big problem is that there's no incentive for maintainers to stabi= lise > > 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 a= dd > activly maintained applications, that can be released seperatly, but th= at > do not are active part of the KDE release. But we should definitly keep > e.g. korganizer and kmail in freeze together with kdebase. Ok, I think we had a lot of very good arguments against a pure kdelibs/kdebas= e=20 release (see esp. posts from Thomas Diehl, David Faure and Tim Jansen). T= his=20 entire thread started because of application duplication and how much wor= k it=20 adds for non-coders. Because this comes up very often we need to find som= e=20 kind of solution, I think. I like the idea of opening another module that is explicitely not part of= the=20 KDE release and would like to propose "kdeprime". To ensure it is not =20 kdenonbeta2 there should be some rules:=20 - Every app that is not maintained will be removed - Every app should be in a release state when a new KDE is released (to g= ive=20 an incentive for non-coders to work on the apps although they are not par= t of=20 the official thing).=20 - For an application to be moved to this module the same applies as for a= ll=20 other modules (except nonbeta), but the programs here do not follow a com= mon=20 theme (like multimedia, education etc.) and may duplicate functionality. - Applications that cannot be agreed upon to be in one of the other modul= es=20 (for whatever reason) will be moved here, or out of KDE. No further=20 discussion ;-) All applications in this module will be released individually, but with a= s=20 much automation as possible. So, to summarize: KDE release will be regarded as a KDE Distribution with all the polishing= =20 necessary (including application selection) and including all modules min= us=20 kdenonbeta and kdeprime. kdeprime will be the module for all release-read= y=20 apps that are not part of the official KDE and are released separately, b= ut=20 take advantage of the KDE development process. If this idea is accepted as a solution I will take care of this module an= d=20 work on the automation. Help and suggestions will of course be very wellc= ome=20 :-) Greetings, Klas