Merging Of Contributions

Board Discuss
#21

Hi all,

I would expect the ESC should intervene and cut out the
politics.

I believe that politics have nothing to do with what happened.

Your grep shows that there aren't that many "lool" that could be renamed "cool" by mistake so I guess it's unlikely for it to happen again.

I've noticed the very positive and prompt review of this incident by Thorsten so it's nice to see that solutions that work for all can be found quickly when the will is there :wink:

Ciao

Paolo

#22

Hi all,

Hi all,

I would expect the ESC should intervene and cut out the
politics.

I believe that politics have nothing to do with what happened.

Your grep shows that there aren't that many "lool" that could be
renamed "cool" by mistake so I guess it's unlikely for it to happen
again.

I've noticed the very positive and prompt review of this incident by
Thorsten so it's nice to see that solutions that work for all can be
found quickly when the will is there :wink:

I try a bit to give an overview on the latest changes of the file in
discussion:

The naming in the source code contains 'lool' in it until it was changed
five month ago to 'cool'. Thus the original naming was:

window.webkit.messageHandlers.lool !== undefined)
window.webkit.messageHandlers.lool.postMessage('EXITSLIDESHOW', '*');

The change from 'lool' to 'cool' created a break for at least two known
downstream consumer projects.

In my view it is not usual for an OSS project to support within its main
branch downstream consumer projects which make a breaking change in
their own external hosted code.

If we'd do that the next downstream consumer project probably asks
LibreOffice and its voluteers to support a further (naming) break (e.g.
naming it 'silly').

Thus the first solution would be to get the old naming back ('lool') and
fix the break for at least two downstream consumer projects. This was
done with the submitted patch.

Then there were a complain that this would break one downstream consumer
project and I as a volunteer should provide a fix also for that project.
There are two reasons why I think this couldn't be a solution. It's not
a task for a volunteer to fix issues introduced within the external
hosted source code of that project. And if TDF and its community would
do the fix this way another consumer project with a breaking change
could ask for the same.

But if you grep to the LibreOffice source code within core you'll find
out that there are outside this file no other namings of variables ,
functions etc. with 'lool' or 'cool' inside. Thus the naming in the file
could be viewed as used by fault. I share Michael's view in this case. I
grepped also for 'lok' with a much bigger output. Thus as Michael and
also Miklos proposed the renaming with 'lok' instead of 'cool' could be
a solution. But in the end this would break not only one or two
downstream consumer projects but all three known.

If I look at the Python world there are always deprecation warnings long
time before a breaking change. I'd like to avoid the need of such a
time-frame. We currently know that at least three projects are affected
from the naming change. Thus I propose to provide in addition a code
patch and make a pull request to every of this three downstream consumer
projects.

Regards,
Andreas

#23

Hi,

Hi all,

Hi all,

I would expect the ESC should intervene and cut out the
politics.

I believe that politics have nothing to do with what happened.

Your grep shows that there aren’t that many “lool” that could be
renamed “cool” by mistake so I guess it’s unlikely for it to happen
again.

I’ve noticed the very positive and prompt review of this incident by
Thorsten so it’s nice to see that solutions that work for all can be
found quickly when the will is there :wink:

I try a bit to give an overview on the latest changes of the file in
discussion:

The naming in the source code contains ‘lool’ in it until it was changed
five month ago to ‘cool’. Thus the original naming was:

window.webkit.messageHandlers.lool !== undefined)
window.webkit.messageHandlers.lool.postMessage(‘EXITSLIDESHOW’, ‘*’);

The change from ‘lool’ to ‘cool’ created a break for at least two known
downstream consumer projects.

Just for the record, the incriminated code is used solely by the iOS app (Collabora Office). Are there other iOS apps that broke because of the lool->cool change? As far as I’m concerned there aren’t any. It’s good that we discussed the issue at length, and will have a vendor neutral message handler name finally. :wink:

Regards,
Andras

#24

Hi,

Hi,

    Hi all,

    > Hi all,
    >
    >> I would expect the ESC should intervene and cut out the
    >> politics.
    >
    > I believe that politics have nothing to do with what happened.
    >
    > Your grep shows that there aren't that many "lool" that could be
    > renamed "cool" by mistake so I guess it's unlikely for it to happen
    > again.
    >
    > I've noticed the very positive and prompt review of this incident by
    > Thorsten so it's nice to see that solutions that work for all can be
    > found quickly when the will is there :wink:
    >
    I try a bit to give an overview on the latest changes of the file in
    discussion:

    The naming in the source code contains 'lool' in it until it was
    changed
    five month ago to 'cool'. Thus the original naming was:

    window.webkit.messageHandlers.lool !== undefined)
    window.webkit.messageHandlers.lool.postMessage('EXITSLIDESHOW', '*');

    The change from 'lool' to 'cool' created a break for at least two
    known
    downstream consumer projects.

Just for the record, the incriminated code is used solely by the iOS
app (Collabora Office). Are there other iOS apps that broke because of
the lool->cool change? As far as I'm concerned there aren't any. It's
good that we discussed the issue at length, and will have a vendor
neutral message handler name finally. :wink:

I'd appreciate if you read my message completely. And I'd be curious if
there is common opinion among you and your colleagues. Currently I'm a
bit puzzled.

Regards,
Andreas

#25

Hi Andras,

On 02/09/2022 18:47, Andras Timar wrote:

Hi,

On Fri, Sep 2, 2022 at 5:38 PM Andreas Mantke <maand@gmx.de> wrote:

Hi all,

Am 01.09.22 um 23:16 schrieb Paolo Vecchi:

Hi all,

On 01/09/2022 22:47, Michael Meeks wrote:

I would expect the ESC should intervene and cut out the
politics.

I believe that politics have nothing to do with what happened.

Your grep shows that there aren’t that many “lool” that could be
renamed “cool” by mistake so I guess it’s unlikely for it to happen
again.

I’ve noticed the very positive and prompt review of this incident by
Thorsten so it’s nice to see that solutions that work for all can be
found quickly when the will is there :wink:

I try a bit to give an overview on the latest changes of the file in
discussion:

The naming in the source code contains ‘lool’ in it until it was changed
five month ago to ‘cool’. Thus the original naming was:

window.webkit.messageHandlers.lool !== undefined)
window.webkit.messageHandlers.lool.postMessage(‘EXITSLIDESHOW’, ‘*’);

The change from ‘lool’ to ‘cool’ created a break for at least two known
downstream consumer projects.

Just for the record, the incriminated code is used solely by the iOS app (Collabora Office).

Apparently not?

Are there other iOS apps that broke because of the lool->cool change?

Isn’t Andreas saying that it broke two downstream consumer projects?

As far as I’m concerned there aren’t any.

It seems to transpire that at least 2 other projects were concerned by it.

It’s good that we discussed the issue at length, and will have a vendor neutral message handler name finally. :wink:

It would have been great to have a discussion before the “lool” handler was changed to a “non-vendor neutral” one.

If I understood well a change to “lok” would break even more projects so what about reverting it to a vendor neutral name like “lool” so that the issue is fixed for 3 downstream consumer projects?

Regards,
Andras

Ciao

Paolo

#26

Hi Andreas, all,

Andreas Mantke wrote:

> Just for the record, the incriminated code is used solely by the iOS
> app (Collabora Office). Are there other iOS apps that broke because of
> the lool->cool change? As far as I'm concerned there aren't any. It's
> good that we discussed the issue at length, and will have a vendor
> neutral message handler name finally. :wink:

I'd appreciate if you read my message completely. And I'd be curious if
there is common opinion among you and your colleagues. Currently I'm a
bit puzzled.

Let's please assume good intentions on all sides. TTBOMK, there's
indeed currently only Collabora providing binaries for iOS.

But honestly, that's all besides the point, and this entire thread is
dealing with the issue from the wrong end.

Andreas, can you please first and foremost interact with the reviewers
on gerrit? I'm convinced we can address all remaining questions there
& get a suitable change merged.

And **only** if that fails, it's justified to consume more board &
member's time here. Right now, there's purely technical matters to be
solved.

Cheers,

-- Thorsten

#27

Hi Thorsten and all,

Hi Andreas, all,

Andreas Mantke wrote:

Just for the record, the incriminated code is used solely by the iOS
app (Collabora Office). Are there other iOS apps that broke because of
the lool->cool change? As far as I'm concerned there aren't any. It's
good that we discussed the issue at length, and will have a vendor
neutral message handler name finally. :wink:

I'd appreciate if you read my message completely. And I'd be curious if
there is common opinion among you and your colleagues. Currently I'm a
bit puzzled.

Let's please assume good intentions on all sides.

We surely assume good intentions from all and that wasn't at all put in doubt.

TTBOMK, there's
indeed currently only Collabora providing binaries for iOS.

OK so there is a misunderstanding?

Reading Andreas emails I had the impression that the handler (lool/cool/lok) in question isn't only used by Collabora's iOS products but also other "downstream consumer projects".

Did I get it completely wrong?

But honestly, that's all besides the point, and this entire thread is
dealing with the issue from the wrong end.

I surely do not have the skills and the experience to deal with the development end of this thread but it's good to learn more about the interaction between LibreOffice core and other projects.

There is probably a code/technological side but also a policies/projects interaction end that the board might need to evaluate so that downstream projects do not suffer if changes in core aren't properly notified and coordinated.

And **only** if that fails, it's justified to consume more board &
member's time here. Right now, there's purely technical matters to be
solved.

As above, it doesn't seem to be purely a technical matter so, unless I missed some documents/policies, there seems to be a need to have a clear coordination so that changes do not affect current and future projects and LibreOffice Technology's based consumers/providers.

Cheers,

-- Thorsten

Ciao

Paolo

#28

Hi all,

Hi Andreas, all,

Andreas Mantke wrote:

Just for the record, the incriminated code is used solely by the iOS
app (Collabora Office). Are there other iOS apps that broke because of
the lool->cool change? As far as I'm concerned there aren't any. It's
good that we discussed the issue at length, and will have a vendor
neutral message handler name finally. :wink:

I'd appreciate if you read my message completely. And I'd be curious if
there is common opinion among you and your colleagues. Currently I'm a
bit puzzled.

Let's please assume good intentions on all sides. TTBOMK, there's
indeed currently only Collabora providing binaries for iOS.

But honestly, that's all besides the point, and this entire thread is
dealing with the issue from the wrong end.

Andreas, can you please first and foremost interact with the reviewers
on gerrit? I'm convinced we can address all remaining questions there
& get a suitable change merged.

already done. As required the commit got another (better) commit message.

Sorry for the delay on Gerrit but I wasn't able to login. Thanks to
Guilhem, who fixed that for me, it works again now.

Regards,
Andreas

#29

Hi Andreas,

Hi all,

although I'm a bit discomposed about the process of today and the last
days I try to be as objective as possible.

Hi all,

Hi Andreas, all,

Andreas Mantke wrote:

Just for the record, the incriminated code is used solely by the iOS
app (Collabora Office). Are there other iOS apps that broke because of
the lool->cool change? As far as I'm concerned there aren't any. It's
good that we discussed the issue at length, and will have a vendor
neutral message handler name finally. :wink:

I'd appreciate if you read my message completely. And I'd be curious if
there is common opinion among you and your colleagues. Currently I'm a
bit puzzled.

Let's please assume good intentions on all sides. TTBOMK, there's
indeed currently only Collabora providing binaries for iOS.

But honestly, that's all besides the point, and this entire thread is
dealing with the issue from the wrong end.

Andreas, can you please first and foremost interact with the reviewers
on gerrit? I'm convinced we can address all remaining questions there
& get a suitable change merged.

already done. As required the commit got another (better) commit message.

Sorry for the delay on Gerrit but I wasn't able to login. Thanks to
Guilhem, who fixed that for me, it works again now.

As you already know I submitted on August, 26 a patch to LibreOffice
core which fixes a name change. This name change was done about five
month before and changes the naming from 'lool' to 'cool'. This name
change breaked the connection from the LibreOffice Online repository and
its downstream consumers. It also changed the naming from a vendor
neutral to the naming of a commercial OSS company.

The patch was tested by Jenkins without any issues. Then a developer
with review permissions gave a +2 and marked the patch ready for
integration.

Because nobody with ther permission to merge the patch took care of the
patch and submitted it to the core repo I asked about the procedure with
volunteer patches some days later here (and on the developer list too).

I got the message then that the commit message is not okay, because it
didn't reflect the code change. I amended the commit message as requested.

Then after some more comments on Gerrit one developer edited my patch.
This patch reverted my changes and added totally different lines of code
to the patch set. The commit message wasn't changed. This totally new
patch set was reviewed by the author of the new patch set, marked ready
for integration and merged.

This developer didn't asked me, if I'm fine with the new patch.

Nevertheless the merged patch is marked as signed by me. The new patch
didn't revert the naming change, done about five month ago. The changed
naming to 'cool' stayed in the LibreOffice core repository and it is not
yet clear, if and when this line will be removed ever.

In addition the new patch breaks the connection to two downstream
consumer projects and to the LibreOffice online repository too.

This new patch was merged as signed by me. I wasn't asked if I was fine
with the new patch and I never signed this new patch (and are not fine
with it).

thanks for your summary of the events which, by reading emails and comments in gerrit, seems accurate.

I see this as a violation and ask TDF to de-merge the patch.

Not being a developer I can't judge if there is a violation of any rules (BTW are there any standard rules?), maybe others can check the sequence of events and tell us if that's the best way to manage these situations.

I haven't been involved directly in development for the past 20+ years but following the logic of the patch that has been pushed through, which doesn't fix Andreas issue, this kind of makes sense to me:

SlideShow.prototype.exitSlideShowInApp = function()
{
    if (window.webkit !== undefined &&
        window.webkit.messageHandlers !== undefined &&
        window.webkit.messageHandlers.lok !== undefined)
window.webkit.messageHandlers.lok.postMessage('EXITSLIDESHOW', '*');
    // FIXME remove this in a follow-up commit
    if (window.webkit !== undefined &&
        window.webkit.messageHandlers !== undefined &&
        window.webkit.messageHandlers.cool !== undefined)
window.webkit.messageHandlers.cool.postMessage('EXITSLIDESHOW', '*');
    // FIXME notify the community about the standardisation to lok and remove in 6 months
    if (window.webkit !== undefined &&
        window.webkit.messageHandlers !== undefined &&
        window.webkit.messageHandlers.lool !== undefined)
window.webkit.messageHandlers.lool.postMessage('EXITSLIDESHOW', '*');
}

I thought that the developer that pushed through and merged the current patch could have thought about it to fix the original requests but if it helps then please do merge it in.

In addition: in my opinion there is much space for improving the
interaction with volunteer developers inside the LibreOffice community.
But maybe this only my opinion and everyone else is fine with the
current process.

Maybe it was just a misunderstanding and the delay in answering back due to the fact that you couldn't login into gerrit might have led some to believe that you didn't want to interact with the issue and the proposed changes.

I'm sure everyone involved will look objectively at what happened and will help in improving communication and processes.

Regards,
Andreas

Ciao

Paolo

#30

Hi all,

although I'm a bit discomposed about the process of today and the last
days I try to be as objective as possible.

Hi all,

Hi Andreas, all,

Andreas Mantke wrote:

Just for the record, the incriminated code is used solely by the iOS
app (Collabora Office). Are there other iOS apps that broke because of
the lool->cool change? As far as I'm concerned there aren't any. It's
good that we discussed the issue at length, and will have a vendor
neutral message handler name finally. :wink:

I'd appreciate if you read my message completely. And I'd be curious if
there is common opinion among you and your colleagues. Currently I'm a
bit puzzled.

Let's please assume good intentions on all sides. TTBOMK, there's
indeed currently only Collabora providing binaries for iOS.

But honestly, that's all besides the point, and this entire thread is
dealing with the issue from the wrong end.

Andreas, can you please first and foremost interact with the reviewers
on gerrit? I'm convinced we can address all remaining questions there
& get a suitable change merged.

already done. As required the commit got another (better) commit message.

Sorry for the delay on Gerrit but I wasn't able to login. Thanks to
Guilhem, who fixed that for me, it works again now.

As you already know I submitted on August, 26 a patch to LibreOffice
core which fixes a name change. This name change was done about five
month before and changes the naming from 'lool' to 'cool'. This name
change breaked the connection from the LibreOffice Online repository and
its downstream consumers. It also changed the naming from a vendor
neutral to the naming of a commercial OSS company.

The patch was tested by Jenkins without any issues. Then a developer
with review permissions gave a +2 and marked the patch ready for
integration.

Because nobody with ther permission to merge the patch took care of the
patch and submitted it to the core repo I asked about the procedure with
volunteer patches some days later here (and on the developer list too).

I got the message then that the commit message is not okay, because it
didn't reflect the code change. I amended the commit message as requested.

Then after some more comments on Gerrit one developer edited my patch.
This patch reverted my changes and added totally different lines of code
to the patch set. The commit message wasn't changed. This totally new
patch set was reviewed by the author of the new patch set, marked ready
for integration and merged.

This developer didn't asked me, if I'm fine with the new patch.

Nevertheless the merged patch is marked as signed by me. The new patch
didn't revert the naming change, done about five month ago. The changed
naming to 'cool' stayed in the LibreOffice core repository and it is not
yet clear, if and when this line will be removed ever.

In addition the new patch breaks the connection to two downstream
consumer projects and to the LibreOffice online repository too.

This new patch was merged as signed by me. I wasn't asked if I was fine
with the new patch and I never signed this new patch (and are not fine
with it).

I see this as a violation and ask TDF to de-merge the patch.

In addition: in my opinion there is much space for improving the
interaction with volunteer developers inside the LibreOffice community.
But maybe this only my opinion and everyone else is fine with the
current process.

Regards,
Andreas

#31

Hi Andreas,

Did you already ask on the developer list for explanation etc. on what happened (and looks unfortunate indeed). If so, what did that learn you? If not, can you please ask the relevant questions there?

Thanks,
Cor

#32

Hi Andreas/all,

Hi Paolo, hi all,

Hi Andreas,

(...)

This new patch was merged as signed by me. I wasn't asked if I was fine
with the new patch and I never signed this new patch (and are not fine
with it).

thanks for your summary of the events which, by reading emails and
comments in gerrit, seems accurate.

I see this as a violation and ask TDF to de-merge the patch.

Not being a developer I can't judge if there is a violation of any
rules (BTW are there any standard rules?), maybe others can check the
sequence of events and tell us if that's the best way to manage these
situations.

It's really not fair to turn ones commit into the opposite and sign this
new patch with the original author (of the opposite).

I personally haven't understood the logic of it as I'm not a developer but I would have thought that when the involved people realised that they forgot to deal with the initial the scope of the request then they would have done something about it.

I would have also thought that there were some processes to deal with misunderstandings and disagreements between developers but even the intervention of one board member directly on gerrit didn't seem to help in clarifying things.

I'm sure he will soon realise that your fix has been forgotten and he will do his best to objectively and impartially deal with it.

How would you
describe such a behavior in the 'analog' live?

I take the fifth (as some say the other side of the pond)

I haven't been involved directly in development for the past 20+ years
but following the logic of the patch that has been pushed through,
which doesn't fix Andreas issue, this kind of makes sense to me:

SlideShow.prototype.exitSlideShowInApp = function()
{
    if (window.webkit !== undefined &&
        window.webkit.messageHandlers !== undefined &&
        window.webkit.messageHandlers.lok !== undefined)
window.webkit.messageHandlers.lok.postMessage('EXITSLIDESHOW', '*');
    // FIXME remove this in a follow-up commit
    if (window.webkit !== undefined &&
        window.webkit.messageHandlers !== undefined &&
        window.webkit.messageHandlers.cool !== undefined)
window.webkit.messageHandlers.cool.postMessage('EXITSLIDESHOW', '*');
    // FIXME notify the community about the standardisation to lok and
remove in 6 months
    if (window.webkit !== undefined &&
        window.webkit.messageHandlers !== undefined &&
        window.webkit.messageHandlers.lool !== undefined)
window.webkit.messageHandlers.lool.postMessage('EXITSLIDESHOW', '*');
}

I thought that the developer that pushed through and merged the
current patch could have thought about it to fix the original requests
but if it helps then please do merge it in.

I think about submitting a new patch and let's see if this will not be
turned into the opposite again.

Please do that. I'm sure everyone understood the situation and they'll look after you much better.

In addition: in my opinion there is much space for improving the
interaction with volunteer developers inside the LibreOffice community.
But maybe this only my opinion and everyone else is fine with the
current process.

Maybe it was just a misunderstanding and the delay in answering back
due to the fact that you couldn't login into gerrit might have led
some to believe that you didn't want to interact with the issue and
the proposed changes.

I don't judge about this. I find the work with Gerrit sometimes not very
intuitive.

You know a lot more than I do I see :wink:

I thought about submitting that patch myself but I gave up before starting as it isn't a tool I ever used or that I will generally use.

I'm sure everyone involved will look objectively at what happened and
will help in improving communication and processes.

I think it is in the interest of the board to foster a good
communication behavior inside the LibreOffice developer (volunteer and
paid) group. And I hope it also a goal that every developer (independent
from his role and skills) will be treated sympathetically, thus she/he
felt very welcome inside the community.

In addition I think it is also in the best interest of TDF/LibreOffice
community to establish such behavior/environment between volunteers of
different areas of contribution too. In my view there is no superior
group of volunteers. All talents and a different sort of contributions
are needed to drive LibreOffice and it community forward and make the
project successful.

Thanks for your very useful suggestions that I'm sure will be seriously considered to improve the experience of those that make their first steps in contributing code to LibreOffice.

Regards,
Andreas

Ciao

Paolo

#33

Hi Paolo, hi all,

Hi Andreas,

(...)

This new patch was merged as signed by me. I wasn't asked if I was fine
with the new patch and I never signed this new patch (and are not fine
with it).

thanks for your summary of the events which, by reading emails and
comments in gerrit, seems accurate.

I see this as a violation and ask TDF to de-merge the patch.

Not being a developer I can't judge if there is a violation of any
rules (BTW are there any standard rules?), maybe others can check the
sequence of events and tell us if that's the best way to manage these
situations.

It's really not fair to turn ones commit into the opposite and sign this
new patch with the original author (of the opposite). How would you
describe such a behavior in the 'analog' live?

I haven't been involved directly in development for the past 20+ years
but following the logic of the patch that has been pushed through,
which doesn't fix Andreas issue, this kind of makes sense to me:

SlideShow.prototype.exitSlideShowInApp = function()
{
    if (window.webkit !== undefined &&
        window.webkit.messageHandlers !== undefined &&
        window.webkit.messageHandlers.lok !== undefined)
window.webkit.messageHandlers.lok.postMessage('EXITSLIDESHOW', '*');
    // FIXME remove this in a follow-up commit
    if (window.webkit !== undefined &&
        window.webkit.messageHandlers !== undefined &&
        window.webkit.messageHandlers.cool !== undefined)
window.webkit.messageHandlers.cool.postMessage('EXITSLIDESHOW', '*');
    // FIXME notify the community about the standardisation to lok and
remove in 6 months
    if (window.webkit !== undefined &&
        window.webkit.messageHandlers !== undefined &&
        window.webkit.messageHandlers.lool !== undefined)
window.webkit.messageHandlers.lool.postMessage('EXITSLIDESHOW', '*');
}

I thought that the developer that pushed through and merged the
current patch could have thought about it to fix the original requests
but if it helps then please do merge it in.

I think about submitting a new patch and let's see if this will not be
turned into the opposite again.

In addition: in my opinion there is much space for improving the
interaction with volunteer developers inside the LibreOffice community.
But maybe this only my opinion and everyone else is fine with the
current process.

Maybe it was just a misunderstanding and the delay in answering back
due to the fact that you couldn't login into gerrit might have led
some to believe that you didn't want to interact with the issue and
the proposed changes.

I don't judge about this. I find the work with Gerrit sometimes not very
intuitive.

I'm sure everyone involved will look objectively at what happened and
will help in improving communication and processes.

I think it is in the interest of the board to foster a good
communication behavior inside the LibreOffice developer (volunteer and
paid) group. And I hope it also a goal that every developer (independent
from his role and skills) will be treated sympathetically, thus she/he
felt very welcome inside the community.

In addition I think it is also in the best interest of TDF/LibreOffice
community to establish such behavior/environment between volunteers of
different areas of contribution too. In my view there is no superior
group of volunteers. All talents and a different sort of contributions
are needed to drive LibreOffice and it community forward and make the
project successful.

Regards,
Andreas

#34

Hi Andreas,

I suggested it earlier, let me now strongly suggest it again - if you
want actual, code-related or technical questions solved for real,
please let's bring it to the attention of the developer
community. Here's the way to get direct interactions: [1].

Andreas Mantke wrote:

Nevertheless the merged patch is marked as signed by me.

We don't tend to use that commit msg metadata line in the project, so
that's probably been an oversight. But I agree, would have been better
to remove that.

The new patch didn't revert the naming change, done about five month
ago. The changed naming to 'cool' stayed in the LibreOffice core
repository and it is not yet clear, if and when this line will be
removed ever.

The merged patch resolves the issue in a way that is consistent with
project conventions (don't break downstream consumers w/o time to
adapt, and use consistent naming (lok in this case)).

There was no answer on the question whether you'd want to provide the
change yourself, so someone else jumped in & did it (after having
offered it). That's helpful IMO.

In addition the new patch breaks the connection to two downstream
consumer projects and to the LibreOffice online repository too.

We should discuss technical needs of downstream projects on the dev
list. Can you please follow-up there? It would be of particular
interest, where those downstream git repos are hosted, and what
platforms they build for.

[1] https://wiki.documentfoundation.org/Development/GetInvolved#Connect_to_our_communication_channels

Cheers,

-- Thorsten

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