> If the libs are separated from the apps and the apps
themselves are
> distributed independently, then:
> * it is more difficult to predict which components (and
in which versions)
> other people have installed (think of COMBINED
DOCUMENTS)
which translate into more bugs that can't be easily
reproduced... as you need
to have the exact same set of components and so a more
complicated life for
developers.
> * more frustrations for packagers (and users) after
all, because they have
> to deal with many more tar balls and packages, which
also leads to:
anyway, in most decent distributions, koffice is splited,
let say you just
want krita, then you just install krita and kolibs. And so,
it would be
better to encourage packagers to split koffice from the
tarball. Or maybe we
can deliver splited tarball.
> * translations? handbooks? (a language pack for each
app for each
> language???) * Versioning of apps? The need to release
"soon" after a
> kolibs release.
>
> I think we can avoid the last issue by providing
"full" translation
> packages for all of KOffice, like it's done for KDE
itself.
but kde is release at one time in the whole, exactly like
koffice.
> Despite the drawbacks, I would actually prefer
splitting things up. KOffice
> has quite some momentum right now, each component
(almost?) has people
> working on them, and so on.
>
> Another benefit that will come up later is that 3rd
party applications can
> be more easily provided, after all, since they are in
the same boat
> (separated from kolibs) as the actual applications
themselves.
Why it would bennefit to 3rd party application ? I am
working on a 3rd party
application (unreleased yet) using kolibs, and I don't see
what benefice I
will get.
> Another
> thing is scaled-down versions of KOffice for embedded
devices - which will
> work better with splitting.
Then again why ? Koffice is allready organizes in module.
Look at what ingwa
is doing for kids office.
The only real benefice I can see in spliting is for new
applications that are
often released on a short schedule. Then the good solution
is for new
applications to be develloped outside koffice and to
integrate koffice later
when they are ready for the 9/12 month release cycle.
--
--- Cyrille Berger ---
_______________________________________________
koffice-devel mailing list
koffice-devel kde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel
|