[DISCUSS] LibreOffice Online freeze-related topics

Board Discuss
#1

Hi,

3. Point the OpenGrok repository to the mirrored Collabora Online
repository, for the time being, as long as the development is not
happening at TDF

It might be helpful to have usage metrics for {OpenGrok online. During
the past 2 weeks I count 535 hits from 30 distinct IPs, half of which
with ≤15 requests. In comparison, for core I count 27k hits from 419
distinct IPs, 284 of which with ≤15 requests.

Anyway, why should TDF assist with tooling for a project that's no
longer developed under its umbrella? IMHO {OpenGrok falls into the same
category as build bots, and {OpenGrok's online repository should be
removed just like we shutdown the online build bot. And if there is
interest in keeping these around, they should point to the state prior
to the fork, not to a new upstream.

Bugzilla, the dashboard, and weblate are different and I think it's
important for posterity to preserve (keep that public) issues, metrics,
and l10n contributions of the project from its inception up to the fork.

FWIW I also think it's wrong to mirror references of https://git.libreoffice.org/online
from an external repository. https://listarchives.tdf.io/i/gVuesWC6ZI0MUequqiqJ3nrc
reads “1. to freeze (not delete) the "online" repository at TDF's git,
for the time being” and “1b. to switch the https://github.com/libreoffice/online
mirror to instead mirror the Collabora repo”. I assume “freeze” in 1. was
not meant to turn https://git.libreoffice.org/online it into a read-only
mirror? That's anyway not how I read the decision.

#2

Hi,

3. Point the OpenGrok repository to the mirrored Collabora Online
repository, for the time being, as long as the development is not
happening at TDF

It might be helpful to have usage metrics for {OpenGrok online. During
the past 2 weeks I count 535 hits from 30 distinct IPs, half of which
with ≤15 requests. In comparison, for core I count 27k hits from 419
distinct IPs, 284 of which with ≤15 requests.

Anyway, why should TDF assist with tooling for a project that's no
longer developed under its umbrella? IMHO {OpenGrok falls into the same
category as build bots, and {OpenGrok's online repository should be
removed just like we shutdown the online build bot. And if there is
interest in keeping these around, they should point to the state prior
to the fork, not to a new upstream.

Guilhem has a solid point here, if anyone leaves our project why should us go behind them?

#3

+1

Paolo

#4

Hi!

On Wed, Jan 13, 2021 at 4:53 PM Daniel Armando Rodriguez <drodriguez@documentfoundation.org> wrote:

Guilhem has a solid point here, if anyone leaves our project why should
us go behind them?

The people involved have not left our community or the LibreOffice project (yet). They continue to be our colleagues, friends and indeed contributors of all kinds, including upstreaming LO improvements that arise from COOL. Please be kind.

There’s a dispute in progress that eventually could be resolved if only the words being used about it were conciliatory. Provocations don’t generally resolve disputes. While it makes sense to “freeze” (interpreting that sensibly for each part of the matter) it does not make sense to behave as if we are removing every trace and building a competing project (yet).

Cheers,

Simon

#5

Guilhem Moulin wrote:

I assume “freeze” in 1. was not meant to turn
https://git.libreoffice.org/online it into a read-only mirror?
That's anyway not how I read the decision.

Agreed. The idea was to mirror on github, and freeze on gerrit.

Cheers,

-- Thorsten

#6

Guilhem Moulin wrote:

Anyway, why should TDF assist with tooling for a project that's no
longer developed under its umbrella?

Why not? It's a useful service, and the instance is running anyway.

(for the record, it's not without precedent that TDF helps out
not-directly-affiliated projects. it's I believe a good habit, that's
also cultivated in other opensource foundations, to help each other
out every once in a while...)

In a word, no skin off our back, IMO.

Cheers,

-- Thorsten

#7

Hi Simon,

you are absolutely right in saying that colleagues, friends and contributors of all kinds are all part of the fantastic TDF community and we all have to work together to make sure this community thrives.

In regards to projects developed by third parties/companies we naturally have to establish a clear and balanced relationship and decide if TDF should support, through marketing or infrastructure, those companies that develop projects that are not part yet/anymore of the TDF family. So in that sense I believe both Guilhelm and Daniel are correct.

There have been discussion in the past of helping out other non directly affiliated organisations and I think that is something we should develop further but before doing so we should set clear rules that apply to all so that we cannot be accused of preferential treatment toward anyone.

In this specific case there is no agreement or rules set to allow a third party to develop its own product using community funded infrastructure so IMHO the provision of those services should not be permitted until a set of rules that specifies who or what projects are eligible to be supported is drafted and agreed on.

Best regards

Paolo

On 13/01/2021 18:28, Simon Phipps wrote:

Hi!

On Wed, Jan 13, 2021 at 4:53 PM Daniel Armando Rodriguez <drodriguez@documentfoundation.org> wrote:

Guilhem has a solid point here, if anyone leaves our project why should
us go behind them?

The people involved have not left our community or the LibreOffice project (yet). They continue to be our colleagues, friends and indeed contributors of all kinds, including upstreaming LO improvements that arise from COOL. Please be kind.

There’s a dispute in progress that eventually could be resolved if only the words being used about it were conciliatory. Provocations don’t generally resolve disputes. While it makes sense to “freeze” (interpreting that sensibly for each part of the matter) it does not make sense to behave as if we are removing every trace and building a competing project (yet).

Cheers,

Simon

Simon Phipps

Office: +1 (415) 683-7660 or +44 (238) 098 7027
Signal/Mobile: +44 774 776 2816

#8

Thanks for that Simon =)

  My understanding of Guilhem's usage stats is that OpenGrok is
essentially un-used (27k core vs. 535 online hits in the last 2 weeks).

  I don't see any terribly compelling reason to keep OpenGrok open and
working vs. online if people object to that, COOL is significantly less
complicated than the LibreOffice core (which as I recall is the 98%+ of
the lines of code here).

  OpenGrok seems an odd locus for a conflict; the costs are rather
trivial. The risk that it might (very slightly) help a group whose
financial, technical and general contribution to TDF and its mission is
quite real is there.

  To soothe my Sayre's Law rash, I'd be well up for simply turning that
bit off if that's easier for syadmin.

  ATB,

    Michael.

#9

Don’t think the kindness being an issue here. Especially if you consider that the fork arises as a result of not being able to mold TDF to taste, let’s be honest with that.

#10

Daniel, the issue is much more complex than that. Happy to explain on a call if you are interested in what honestly happened before you were elected.

S.

#11

Hi Michael,

  To soothe my Sayre's Law rash, I'd be well up for simply turning that
bit off if that's easier for syadmin.

FWIW aside from its first paragraph, I was only wearing my TDF member
hat in my former message. The overhead caused by that repository alone
(whether it's sourced from git.tdf or github) is negligible if I need to
maintain the instance in the first place. Just like the overhead of
keeping the repository active (rw) on gerrit, weblate, dashboard, or
the project alive on bugzilla, etc.

My message was not driven by technical or workload concerns, I just find
the double standard between the different services strange, and I think
it'd be more consistent to drop it or update the refs back to where they
were when development was still under TDF umbrella.

cheers

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.