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
Attachment:
signature.asc
Description: PGP signature
