[libreoffice-projects] minutes of ESC call ...

[David Tardon]

Hi,

On Fri, Oct 11, 2013 at 11:56:49AM +0200, Alex Thurgood wrote:
> Le 11/10/2013 11:21, Stephan Bergmann a écrit :
> 
> >But what was the story with mysql-connector-ooo, these days apparently
> >enabled via a switch called --enable-ext-mariadb-connector?  That switch
> >is off by default, and it is not mentioned in any distro-configs/*.conf,
> >so appears to be effectively dead code.  Or was that the extension that
> >cannot be included in installation sets for whatever reason (and is only
> >included in our source tree to make it easy to build it)?  I guess
> >Lionel knows.
> >
> 
> To the extent that I can get a successful build, I have been
> building on Mac OSX (and to a certain extent on Linux 32/64 for
> testing purposes), near enough on a daily basis, with a kitchen sink
> approach to the extensions because no-one else does them - certainly
> not TDF.

You are wrong. TDF official builds include presentation-minimizer,
nlpsolver and wiki-publisher. They do not include mysql-connector-ooo,
but apparently nobody remembers if that was a conscious decision or if
it "just happened". That is why Stephan asked. The other extensions we
have switches for we _do not_ build (and never have): we just allow to
download the .oxt files and put them into the installation. (And since
virtually nobody cares about them, nobody checks if there is a newer
version either...)

> The same goes with the other extensions. Perhaps it is not in TDF's
> interest to have all that spurious extension code lying around, but
> in that case IMHO a clear decision should be taken to either exclude
> it from the repo, have it hosted separately with instructions on how
> to build/install.

Where has anyone said that? I clearly separated the exensions into two
categories in my mail:
1. These whose code is inside libreoffice. The idea is to convert them
   to normal components, because it buys us nothing to have them as
   extensions. (Or drop the code if noone appears to use them. Which
   seems not to be the case, so that possibility is out.)
2. These we take from outside. There is _no_ code for these inside
   libreoffice that we could drop (or host separately with instructions
   etc. etc.) We just download them from third party sites like anyone
   else. And the only reason they are handled inside libreoffice at all
   is/was OxygenOffice.

> Honestly, if we are no longer going to care for
> the "ext" extensions that are currently in the repo, why have them
> at all ?

As I have already said, most of the extensions is not in the repo at
all. That is why we are discussing whether there is any advantage to
allow to include them in the install sets.

> 
> I'm merely attempting to understand the reasoning into the
> decision-making process that determines whether or not an extension
> makes it into the main code, and at the moment I'm at a loss to
> understand how that reasoning works, as it all seems rather opaque
> to me.

There is only one rule: "our" extensions (that have source code inside
libreoffice, i.e., the four I have already mentioned) should be
de-extensionized, because to have them as extensions does not have any
advantage to anyone. That is why I called them "internal extensions" in
my previous mail. Does that word combination not feel like an oxymoron
to you?

That we allow to bundle third-party extensions in the installation is an
historical accident and we have not decided anything about it (yet).

D.