Hi Kay, Apparently I missed your mail - sorry for that :-(
On Wednesday 09 April 2008 15:35, Kay Ramme - Sun Germany - Hamburg wrote: > just wanted to suggest that re-using one or the other already existing > structure for package re-organization would have some benefits. Possible > candidates IMHO are: > > -1- projects > -2- modules > > You more or less already ruled out the modules approach, arguing along > the line, that it would be too many resulting packages, which I > basically agree to. > > So let's take a look a mirroring the (code) projects into the package > structure, we would get: > > api > dba > documentation > external > framework > graphics > gsl > installation > l10n > oi (obsolet, but still used) > porting > qa > sc > script (obsolet, but still used) > sw > tools > ucb > udk > ui > util > whiteboard (obsolet, but still used) > xml > > These are slightly more than in your suggestions (19 vs. 16), but still > seems to be manageable, the structure is partly similar. Benefits would be: > - Known package owner. > - No discussions where a new module belongs to etc. > - Already defined and established. > - Easy to find out where a module belongs too: cat <module>/CVS/Repository > > Issues regarding build dependencies might give a hint about wrong module > placement and would need to be fixed anyway. Well, my _only_ motivation for the split are the build dependencies - so if we end up with 20 (sub)packages, or 15, I don't really care :-) Also, the names are not that big deal for me (though I personally prefer better describing names, and a kind of structure in them). What is the real problem from my point of view is that currently you cannot take just one of the projects, and (when you have the dependencies installed) self-containly build it. Also, if you look at eg. framework, you see stuff that is essential for the OOo functionality (desktop) as well as one that can be omitted (binfilter). [Why do we need it: It would be great to have the .rpm/.deb/whatever packages in accord with the build dependencies. It then allows us (the Linux distributors) to build the packages in parallel easily. Another advantage is that it is also easy for the potential contributors to install just the -devel packages of the dependencies, and start with the development in the package where he/she wants to fix something - eg. you (generally) do not have to build everything up to Writer if you want to fix a Writer bug... The Linux distros have mechanisms to install such development setups - eg. 'apt-get build-dep', or 'zypper build-deps-install' (to be in openSUSE 11.0).] But the approach of moving the modules between the projects is generally OK for me. Just let's be careful not to end up in arguments like 'X: This module needs to be built in project A, that way we'll have the smallest dependencies. Y: Yes, but people in the project B know most about it.' :-) So - what can we do as the next step? Should I try to merge your and my list to come up with the 'core' dependencies? Or could you, please? Regards, Jan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
