Proposal: build service for LibreOffice extensions

[Thorsten Behrens]

Hi Hossein, all,

Hossein Nourikhah wrote:
> I suggest to create a build service for LibreOffice extensions, that works
> this way:
> 
> 1. The extension creator provides the source code, and the required
> makefiles. It can be in BASIC, Java, Python, C++, or any other supported
> language. It would be something like SUSE openbuildservice.org for OS
> packages.
>
Hmm. So the OBS is a very peculiar beast, and significant effort is spent,
to keep it secure (for its operators & users) and efficient.

Another example of such a 'build service' for a particular platform is
the F-Droid repo - which also needs significant work to keep running.

Both are quite successful in supporting an ecosystem & a platform
though.

Before discussing the requirements & implementation details of such a
service, therefore perhaps the more important question (before
investing TDF resources) is - does it solve a real problem? And if it
does, what other options would be available to solve it?

> The benefits of such a build service is as follows:
> 
> 1. Make the source code available to everyone, and probably visible in the
>    website similar to userstyles.org, etc
>
That seems easy to enforce (if we want to), w/o a build service.

> 2. Make the build process easier for different architectures, at least for
>    the compiled languages. For the interpreted languages, it would be
>    reviewing, then creating a zip package
>
Yup, I agree. But wouldn't perhaps providing ready-made github/gitlab
actions have a similar, but more universal & reusable effect? It would
also be much cheaper to run & maintain. ;)

> 3. Respond to the concerns about security of the binary extensions.
>
I'm not sure that building from source without _very_ thorough review
of foreign code yields anything but a false sense of security.

> 4. Possibility to clarify the license.
>
That also needs thorough review (we already ask for a license on the
extension site).

> 5. Checking the compatibility and possible problems with different versions
>    of LibreOffice.
>
That's a valid point, but it does not solve our need to commit to
binary compatibility - the problem is not the extensions we don't have
source code for (we can always inspect the binaries), but the
extensions & basic macros nobody ever sees, because they're on
individual users' computers, or internal to organisations.

Cheers,

-- Thorsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 427 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20231013/71196564/attachment.sig>