Hi Mathias,
On Wednesday 30 of April 2008, Mathias Bauer wrote:
> > 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).
>
> What level of granularity are you aiming at? I think that having
> separate packages for modules can work for many if we applied the
> necessary changes to scp2. Of course these changes will be more than
> some tweaking, it looks like a redesign to me.
As I wrote, "Why do we need it: It would be great to have
the .rpm/.deb/whatever packages in accord with the build dependencies." [and
elaborate why it would be so great]. So - take the number of .rpm packages
you would be willing to install by hand to get the OOo running, and you get
the granularity I'm aiming at. For me, anything between 15 and 20 is OK,
anything higher is too much, anything lower is too monolithic again.
> But there are some libraries/modules that are still very big and very
> intertwined with others. Making them available as separated packages
> with a reasobable size would require code changes also - and currently I
> don't see any activity going on to work on that. That's something I
> regret but OTOH I know that this is a resource problem.
That's the next step from my point of view :-)
> > 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.' :-)
>
> I don't understand who modules and projects relate here.
Kay, in the email from 2008-04-09, you could have seen the relevant parts
quoted in my mail. Maybe we should define the terms:
projects: The top-level cvs "modules" [term 'module' used here in the cvs
terminology, not the 'module' defined below] - like gsl, graphics, framework,
api, ...
modules: The one level lower thing - the directories you see top-level when
you checkout the OpenOffice2 alias. Examples: vcl, desktop, sal, ...
The 'projects' are re-used as .openoffice.org, and also for the
mailing lists, hierarchy (project leads), etc.
So - there for sure is a relation, Kay proposed to re-use it, I fear that the
current reuse for the hierarchy and for the webpages will be stopping us.
> Projects are
> completely irrelevant for modularization - we should use the modules as
> units for packages and try to bundle some smaller ones into one package
> so that the number does not become too high. But nobody wants a package
> "filter" or "utilities".
That's either what me (and I belive Kay as well) propose [split the current
mega-big-monolithic sources by bundling the modules into packages, and
distribute them separately], or I don't understand you, sorry.
> > 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?
>
> As long as the lists are project oriented and not module oriented we
> won't succeed. As alway, IMHO. :-)
And here I don't understand you either. So, you say that a list like
"Package/project/whatever_is_the_name 1" contains:
module_A
module_B
module_C
"Package/project/whatever_is_the_name 1" contains:
module_D
is bad, and we need something like
module_A: belongs to "Package/project/whatever_is_the_name 1"
module_D: belongs to "Package/project/whatever_is_the_name 2"
? I don't see the difference...
Regards,
Jan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
