Update to today's call agenda

Hi Daniel, all,

Daniel Armando Rodriguez wrote:

I believe we should know what people expects when downloading a
docker img, if it fits the needing or what do they have to deal
with.

Depends on who's the target audience of that question, I guess.

Possibly the design, or the website list are better places to discuss
this?

Cheers,

-- Thorsten

A survey form would be the best way to go about it.

Also note that - regardless of package availability - as conceived Libreoffice Online is beyond the scope of most individuals as it requires access to cloud infrastructure, familiarity with certificates and a willingness to manage web security. That’s why I have proposed LiOn Pi, which is targeted at individuals.

S.

{Terse? Mobile!}

Happy to support this but no idea how to start. Ordinary users cannot answer "What's the best solution for you to get LOOL?" neither "Which kind of authentication do you prefer? [OpenFoo, LibreBar, PublicQux]". And isn't the setup kind of a stack that needs to be installed with (Next)Cloud, LOOL backend, and (COOL)-UI?

So what I'd need for a survey is a couple of simple questions that everybody can answer. My preferred type of question is multiple-choice with additional "Other" option.

Hi Daniel, all,

Daniel Armando Rodriguez wrote:

I believe we should know what people expects when downloading a
docker img, if it fits the needing or what do they have to deal
with.

Depends on who's the target audience of that question, I guess.

Members, Certified Professionals, sysadmins

In this case our end user should understood, IMO, be Certified professionals, members or IT responsible people.

So, maybe this thread can drop such questions as a result.

A survey form would be the best way to go about it.

Also note that - regardless of package availability - as conceived Libreoffice Online is beyond the scope of most individuals as it requires access to cloud infrastructure, familiarity with certificates and a willingness to manage web security. That's why I have proposed LiOn Pi, which is targeted at individuals.

At least a sysadmin would be willing to deal with, but as far as I know currently is hard enough even for such profiles.

Hi Heiko, all,

Heiko Tietze wrote:

So what I'd need for a survey is a couple of simple questions that
everybody can answer. My preferred type of question is
multiple-choice with additional "Other" option.

Thus my (perhaps unintuitive) suggestion to start discussing the
details on the design list - Daniel already listed a number of
different personas (members, certified professionals, and sysadmins),
and it is not unreasonable to assume they might have different needs.

Cheers,

-- Thorsten

The point has to do with the smooth process they/any must find when deploying such a solution.

On Fri, May 22, 2020 at 4:37 PM Daniel Armando Rodriguez <drodriguez@documentfoundation.org> wrote:

El 2020-05-22 10:33, Heiko Tietze escribió:

On 22.05.20 16:09, Simon Phipps wrote:

A survey form would be the best way to go a about it

Happy to support this but no idea how to start. Ordinary users cannot
answer “What’s the best solution for you to get LOOL?” neither “Which
kind of authentication do you prefer? [OpenFoo, LibreBar, PublicQux]”.
And isn’t the setup kind of a stack that needs to be installed with
(Next)Cloud, LOOL backend, and (COOL)-UI?

So what I’d need for a survey is a couple of simple questions that
everybody can answer. My preferred type of question is multiple-choice
with additional “Other” option.

In this case our end user should understood, IMO, be Certified
professionals, members or IT responsible people.

So, maybe this thread can drop such questions as a result.

That is not acceptable. We should be serving the public, not a technical elitre.

S.

Hi all,

in September 2019, to get another project up and running (in which the
main component is NextCloud), I found myself working on LibreOffice Online.

This was totally a pain. The lack of any consistent documentation (until
May 5 in the INSTALL file there was just written "Left as an exercise to
the reader") was one of the biggest problems. The only way was to rely
on old blog posts found on the internet.

Another totally undocumented topic (obviously I refer to the official
documentation on wiki.documentfoundation.org) was the configuration of a
reverse proxy to work with LOOL, essential since configuring LOOL to use
a non-self signed certificate is even harder.

I experienced how the community was once helpful (e.g. addressing me to
the l10n-docker-nightly and explaining the branches) and once, let's
say, less helpful (quote from the IRC "and why do you think we
(Collabora) would want to help you in creating a competing product?").
Needless to say, this has left me stunned: certainly if I write to the
community I don't expect someone to judge if I'm able to declare a
variable in Javascript or not.

Since then, however, much has been done: Online now has at least a
decent documentation which covers the build of a stable version of the
docker container. Many information are though still missing, a reliable
evaluation of the resources needed to have a stable instance and how
many users it could serve, for example. Clustering LOOL even seems to be
an untouched topic for now (to the public, at least).

Therefore, I totally endorse Paolo's proposal. TDF should, in my
opinion, definitely release working stable binaries of online. Many many
associations out there don't have the money or simply don't need a
professional support just the same way it happens for the client version.

I even agree with Simon: deploying online is horribly hard. I've been
working on some Ansible playbook since a while and I think they could be
soon released. The aim is to provide sysadmins (even myself) an easy way
to deploy LOOL. If we have on the Docker HUB an arm64/amrhf image,
having it working on a RaspberryPi would be just a side effect.

All the best,

Marco

Hi Marco,

Therefore, I totally endorse Paolo's proposal. TDF should, in my
opinion, definitely release working stable binaries of online. Many many
associations out there don't have the money or simply don't need a
professional support just the same way it happens for the client version.

Thanks for bringing this forward and good to see a future contributor
possibly :wink:

What you say, is a clear statement, that we all - the full community -
will think and discuss about when the 'start document', that has been
decided in today's board meeting. I hope that can be ready soon, since
it's a very important and hot topic. I hope you also appreciated the
other parts of the meeting of course.

Greetings,
Cor

Cor Nouws kirjoitti 22.5.2020 klo 22.15:

Hi Marco,

Therefore, I totally endorse Paolo's proposal. TDF should, in my
opinion, definitely release working stable binaries of online. Many many
associations out there don't have the money or simply don't need a
professional support just the same way it happens for the client version.

Thanks for bringing this forward and good to see a future contributor
possibly :wink:

Marco has already written docs in the wiki for some months:
https://wiki.documentfoundation.org/Development/BuildingOnline
https://wiki.documentfoundation.org/Configuring_a_reverse_proxy_for_LOOL

Ilmari

Hi,

This was totally a pain. The lack of any consistent documentation (until
May 5 in the INSTALL file there was just written “Left as an exercise to
the reader”) was one of the biggest problems. The only way was to rely
on old blog posts found on the internet.

Until recently the consensus was that TDF releases source tarballs for LOOL. So there was no demand to write documentation how to create packages, how to build a “product”.

On the other hand it is fully documented in the source code in README files how to build as a developer, if someone wanted to hack on the code.

The docker/l10n-docker-nightly.sh is also quite self-explanatory. (For those, who don’t know what it is: it builds a docker image from source.)

Another totally undocumented topic (obviously I refer to the official
documentation on wiki.documentfoundation.org) was the configuration of a
reverse proxy to work with LOOL, essential since configuring LOOL to use
a non-self signed certificate is even harder.

As TDF did not release binaries, I don’t know who would look for such documentation in TDF wiki. Collabora published documentation for CODE, e.g.:

https://www.collaboraoffice.com/code/apache-reverse-proxy/
https://www.collaboraoffice.com/code/nginx-reverse-proxy/

But there are other good sources of information, too, from integrators.

I even agree with Simon: deploying online is horribly hard. I’ve been

I disagree. It’s a myth. Yes, it can be hard, when firewalls, load balancers, 50000 users etc. are involved. It’s the case when one needs professional support. But for the hobbyist, how hard is it to install CODE with a few clicks in Univention, or to follow my “5 minute” guides?

https://www.collaboraoffice.com/code/quick-tryout-owncloud-docker/

https://www.collaboraoffice.com/code/quick-tryout-nextcloud-docker/

Regards,
Andras

Hi!

I disagree. It’s a myth. Yes, it can be hard, when firewalls, load balancers, 50000 users etc. are involved. It’s the case when one needs professional support. But for the hobbyist, how hard is it to install CODE with a few clicks in Univention, or to follow my “5 minute” guides?

I’m sure you have done a great job for suitably-skilled people wanting a quick evaluation, but the truth is that approach only takes you to the point where the questions start. I have tried to get a LiOn system running at home and have not succeeded in getting anything I can leave running for my family, unlike the Asterisk-based phone system we are using (on a Pi) or the NextCloud appliance we have installed (Pi-based).

This is the LiOn problem TDF needs to fix first to get a TDF-centric user- and skill-base established.

S.

That's a missleading, those profiles can help us to reach the endusers.

My personal take is we should get a product as easy to deploy as WordPress, for instance, to let the end user take the control of their own cloud.

Thank you for valuable input Marco

What makes my worry is the response you got about C'bora under TDF's IRC

And I take you words "an easy way to deploy LOOL" should be provided by TDF, as TDF's mission is to offer a free product to the end user. And that offer should allow a painless implementation.

He has really done a great job, but TDF cannot depend on the goodwill of the members for a product to be implemented. All documentation should be provided to make life a lot easier for everyone.

Hi,

Hi!

I disagree. It’s a myth. Yes, it can be hard, when firewalls, load balancers, 50000 users etc. are involved. It’s the case when one needs professional support. But for the hobbyist, how hard is it to install CODE with a few clicks in Univention, or to follow my “5 minute” guides?

I’m sure you have done a great job for suitably-skilled people wanting a quick evaluation, but the truth is that approach only takes you to the point where the questions start. I have tried to get a LiOn system running at home and have not succeeded in getting anything I can leave running for my family, unlike the Asterisk-based phone system we are using (on a Pi) or the NextCloud appliance we have installed (Pi-based).

If there were binaries for Pi, probably installation would be easy. In fact, I think that Pi support would be a nice community project and would not hurt any commercial interest.

Regards,
Andras

There is already an armht/arm64 LibreOffice, both the one the Raspbian folks distribute and a more up-to-date version in Debian (thanks Rene!).

There is also a work-in-progress Debian package, https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-online (again thanks to Rene).

But I’m told it’s just too hard to unpick all the Javascript packages to make it Debian-installable.

So, if you can help get that sorted maybe we can have some easy LiOn Pi after all! The ideal would be something that runs from the GUI as a NextCloud plug-in that, given the location and credentials of a freshly installed Pi, would squirt LiOn into it and configure both ends to use it.

Cheers!

Simon

Hi,

This was totally a pain. The lack of any consistent documentation (until
May 5 in the INSTALL file there was just written "Left as an exercise to
the reader") was one of the biggest problems. The only way was to rely
on old blog posts found on the internet.

Until recently the consensus was that TDF releases source tarballs for LOOL. So there was no demand to write documentation how to create packages, how to build a "product".

It's not about creating a product but implementing a solution, that's the key.

On the other hand it is fully documented in the source code in README files how to build as a developer, if someone wanted to hack on the code.

The docker/l10n-docker-nightly.sh is also quite self-explanatory. (For those, who don't know what it is: it builds a docker image from source.)

Another totally undocumented topic (obviously I refer to the official
documentation on wiki.documentfoundation.org) was the configuration of a
reverse proxy to work with LOOL, essential since configuring LOOL to use
a non-self signed certificate is even harder.

As TDF did not release binaries, I don't know who would look for such documentation in TDF wiki. Collabora published documentation for CODE, e.g.:

https://www.collaboraoffice.com/code/apache-reverse-proxy/
https://www.collaboraoffice.com/code/nginx-reverse-proxy/

But there are other good sources of information, too, from integrators.

From the community you may want to make implementations that, for example, do not show warnings. If the implementer is willing to deal with that, why not let them?

Another hot topic, for me at least is to provide vendor neutral information.

I even agree with Simon: deploying online is horribly hard. I've been

I disagree. It's a myth. Yes, it can be hard, when firewalls, load balancers, 50000 users etc. are involved. It's the case when one needs professional support. But for the hobbyist, how hard is it to install CODE with a few clicks in Univention, or to follow my "5 minute" guides?

https://www.collaboraoffice.com/code/quick-tryout-owncloud-docker/
https://www.collaboraoffice.com/code/quick-tryout-nextcloud-docker/

Vendor neutral point applies here too.

And I am aware that without C'bora/CIB there would probably be no LOOL, but we are TDF.