[quanta-devel] Re: Subversion repository structure (was: trunk/kdeedu/klettres)

[Andras Mantia]

> [ Please let any further discussion on this topic happen in 
> kdevelop-devel mailinglist ]
I'd like to crossposts to quanta-devel as well, as some of us are not 
subscribed to kdevelop-devel and might miss it.

On Sunday 20 February 2005 00:39, Alexander Dymo wrote:
> Matt is right. We've been following KDE release schedule since KDE
> 3.2 but that is not obligatory for us.

It's not obligatory for anybody, but do you want to follow it for the 
next release (4.0) or not?

> Yes. The questions you stated above are very important. So I'd like
> _any_ kdevelop and kdewebdev developer to present their opinion.
>
> I'll try to share my point of view with you here.
>
> We have now inside "kdevelop" module:
> 1) KDevelop Platform - a set of libraries to develop IDE-like
> applications and kdevelop plugins
> 2) KDevelop Shell - a shell application which can load kdevelop
> plugins 
> 3) Plugins - a set of core and a set of additional plugins 
> 4) Two platform applications: KDevelop IDE and KDevelop Assistant
> which use the same shell and the same plugins
>
> Taking the points above into account I can see the following
> svn (only svn because kde will move very soon) structure:
> 1) platform
> 	lib		#platform libraries
> 	shell		#generic plugin-based shell application
> 	plugins	#core (platform plugins) which are common to all
> 			#platform applications
> 2) kdevelop_ide	#everything for KDevelop IDE
> 	lib
> 	shell
> 	plugins
> 	...
> 3) kdevassistant	#everything for KDevelop Assistant
> 	lib
> 	shell
> 	plugins
> 	...
> 4) kdewebdev	#everything for Quanta and web development
> 	lib
> 	shell
> 	plugins
> 	...
>
> Now, where to put those modules?
> Questions are:
> 1) Will kdewebdev be inside trunk/KDE/ or will it be a separate
> module trunk/kdewebdev?

I'd like to keep it under tunk/KDE. This is because kdewebdev has other 
(standalone) applications, like the HTML image map editor, the XSL 
debugger or the link checker. I'm not including KFileReplace and 
Kommander here as they are not completely related to web 
development. ;-)
 Quanta should remain there as well. Just that to have Quanta, you 
require the KDevelop platform. Now about the shell I have mixed 
feelings. The best would be to have a good general shell, so we don't 
have to write and maintain to shells in different places.

> 2) Where shall the "platform" module be in ("trunk/KDE/kdevplatform"
> or "trunk/kdevplatform" or "trunk/kdevelop/platform")?
> 3) Where shall the kdevelop ide reside?
> 4) What would be the release cycle for all platform applications
> etc. etc.
>
> My answer:
> We can create one root module for all development applications, like:
> "trunk/kdedev"
> Then we can have:
> trunk
> 	kdedev
> 		platform
> 		kdevelop
> 		kdevassistant
> 		quanta
> 		... other applications

This may have the problem that there are other development related 
applications partly in kdewebdev and partly in kdesdk.

> Why do I suggest one module for all development applications? Well, I
> have several good reasons:
> 1) We can schedule kdedev releases either with corresponding KDE
> releases or on our own.

I don't see that we (the Quanta team) would like to release separately 
from KDE in the near/middle-term future.

> 2) kdedev would be the best place to put other applications for
> developers like those currently in kdewebdev (kommander,
> kfilereplace, etc.) As we've already seen, those applications have
> their value not only for web development.

Yes, if we really gather there all the applications related to 
development this will be a plus. But do you realize that this will be 
the biggest module in KDE? Well maybe koffice and kde-i18n is bigger, I 
don't know.

> 3) kdedev would be the best place to put platform stuff. We can't
> really put the platform into kdelibs just because platform is not
> only libraries but also common plugins.

Right. My proposal would be to have a separate modulefor the platform 
and common plugins, like:
trunk/KDE/kdevplatform (contains plugins and the platform)
trunk/KDE/kdewebdev (our stuff)
turnk/kdevelop (your stuff)

The latter two requires the first one. This is inter module dependency, 
but might have some good benefits compared to the all-in-one solution.
There are two possible problems with that one:
1) packaging: what if we/a distribution/whatever wants to package just 
KDevelop or just Quanta? Obviously they won't create a 100MB RPM from 
the whole module. ;-) So we have to offer an easy way to extract only 
one application from there (with the required libraries and plugins).
Also packagers will want to create a "kdevplatform" package with the 
common stuff, otherwise there will be conflicts if both KDevelop and 
Quanta packages have the same files. Aside of the problem of extracting 
the common stuff and the applications in separate packages, there is 
also the need to be extra careful about the dependencies and what is 
put where. The kdevplatform part must be self contained, packagable and 
compilable alone. This is why if it's really alone might make more 
sense.
2) CVS(ok SVN ;-)) users: what if somebody wants just Quanta or just 
KDevelop from the repository? I cannot tell him to check out the mega 
module kdedev and only use half of it. I know it's a pain for many to 
download such a big amount of data (and have it on the disk sitting 
without you ever using it). And I certainly don't want to give them a 
crash-course about how to get it in pieces. 
3) Releases: what if KDevelop wants a different release schedule from 
Quanta? How can it be tagged/branched? Having the platform in a 
separate module (which always follows the KDE release cycle) makes this 
easier. If you decide to release the next KDevelop IDE (with 
C++/Ruby/whatever support) differently from KDE, we could still release 
Quanta with KDE.
4) This is something different and that it's a problem in both cases, 
namely that if we convert Quanta into a plugin, I need to install it 
every time to try out my changes, am I right? Now how do you (plugin 
writers) deal with this cases? I'd like to have the possibility to just 
press Execute program, it builds the plugin, runs the shell and the new 
plugin is loaded, not the old one which is installed. 

> 4) kdedev/platform would provide nice place for common stuff, all
> applications inside kdedev could easily add dependencies to platform.

I agree.

> 5) kdedev would be easy to package either as one big kdedev.tar.gz or
> as a set of separate packages because each application inside kdedev
> would have only one dependency like "quanta -> platform".

See above my concerns.

Andras

-- 
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20050220/dca78533/attachment.sig>