Merging Of Contributions

Hi Regina,

It’s still the ESC’s role to resolve it, not the Board’s. All the work on code is done by individuals, and open source projects don’t get to instruct individuals on what to do or when to do it - there is no SLA. If none of those individuals are interested in prioritising any particular patch, the correct next step is to raise it at the ESC, which exists expressly to resolve differences between the individuals working on the code. TDF’s Board is not expected to intervene in the ESC’s work beyond its recent approval of ESC appointees. The request here is out-of-order.

While delays are frustrating - my own bug reports remain unfixed after a decade - it is also very frustrating to see a contributor circumvent TDF’s well-tested processes, especially for political ends.

Cheers

Simon

Hi Andreas,

On 01/09/2022 18:48, Andreas Mantke wrote:

I remember variable changing going on when LOOL has been forked into
COOL, and the removal of "This file is part of the LibreOffice project
:-(, but I thought that it was affecting only their own repository,
not LibreOffice core so I’m surprised we have references within LO
code to a product that isn’t hosted at TDF.

I thought the same, but … This was the first such thing I stumbled upon.

I guess we’ll have to understand if that is something that should be monitored or not.

Changes like that might affect others that are working on other platforms linked to LibreOffice core and to me it’s not clear if there is or there should be a policy for that.

Not sure if any other project can/should do that and if that affects
others eg. does that variable change create issues to those that are
still using LOOL or something similar?

Does that create issues for you?

It creates issues on slideshow touch gestures in the mobile app. The
Android and the IoS apps are also part of the online repository.

So that is a change in LibreOffice core that breaks your attempt of creating a LOOL derived implementation?

Wondering if it affects also others like OSSII or similar similar projects based on LibreOffice Technology.

Regards,
Andreas

Ciao

Paolo

Hi Paolo,

Hi Andreas,

I remember variable changing going on when LOOL has been forked into
COOL, and the removal of "This file is part of the LibreOffice project
:-(, but I thought that it was affecting only their own repository,
not LibreOffice core so I'm surprised we have references within LO
code to a product that isn't hosted at TDF.

I thought the same, but ... This was the first such thing I stumbled
upon.

I guess we'll have to understand if that is something that should be
monitored or not.

Changes like that might affect others that are working on other
platforms linked to LibreOffice core and to me it's not clear if there
is or there should be a policy for that.

I think there should be clear rules that there should not be any
barriers or something similar in the LibreOffice vanilla code.

But once I saw the changes from 'lool' to 'cool' in the source code I
wonder why the ESC didn't discussed and stopped it.

Not sure if any other project can/should do that and if that affects
others eg. does that variable change create issues to those that are
still using LOOL or something similar?

Does that create issues for you?

It creates issues on slideshow touch gestures in the mobile app. The
Android and the IoS apps are also part of the online repository.

So that is a change in LibreOffice core that breaks your attempt of
creating a LOOL derived implementation?

Wondering if it affects also others like OSSII or similar similar
projects based on LibreOffice Technology.

It will, if they follow the naming convention of LibreOffice and didn't
rename everything to 'cool' or including 'cool' instead of 'lool'.

Regards,
Andreas

Hi all,

TDF's Board is not expected to intervene in the ESC's work beyond its recent approval of ESC appointees. The request here is out-of-order.

I was wondering as well why Andreas would send a request to board-discuss for a patch.

While delays are frustrating - my own bug reports remain unfixed after a decade - it is also very frustrating to see a contributor circumvent TDF's well-tested processes, especially for political ends.

[Communication issue: I'm very surprised to see that you are accusing someone of having "political ends" as if it was the most normal thing to say.
This is not just a "passive aggressive insinuation", it's an actual direct accusation and if you have evidence of mal-intent you should present it together with the accusation. Keep in mind that some got a CoC complaint for a lot less than that (sorry I can't disclose names as complaints should be kept private).]

Looking at the request, then at the patch and the latest description provided I understood that Andreas is working on a project that has a very short window of opportunity set by the Board itself and he's doing his best to get some results as fast as possible. So in a way I kind of understand the attempt as the board itself was involved in setting limits that make what is doing very time sensitive even if it's hardly a justifiable excuse to bypass standard procedures.

While I agree that the ESC should be involved in code related matters this seems to go beyond that as variables in LibreOffice core have been changed to represent the initials of a project not hosted at TDF (LOOL -> COOL) and if I've understood well the change breaks other projects that use the initials of the project still hosted at TDF (LOOL).

That, IMHO, isn't just matter of "code" as a change that introduces a commercial product name in LibreOffice core should have been cleared with the board which I believe would have not agree to it as LibreOffice should be "brand neutral" and create a level playing field for all contributors being voluntary or commercial.
Not being a developer I might get things mixed up but I guess the board should evaluate if the necessary policies and checks are in place.

Ciao

Paolo

Hi Andreas,

I think there should be clear rules that there should not be any
barriers or something similar in the LibreOffice vanilla code.

But once I saw the changes from 'lool' to 'cool' in the source code I
wonder why the ESC didn't discussed and stopped it.

I've noticed your suggestion after I sent my other answer.

I'm surprised that the ESC didn't contact the board to notify us that some changes were more like a "branding" changes that actual improvements necessary in LibreOffice core.

I don't know if the ESC could have done anything about it, I guess it's hard to spot a cool among many lool but then we'll have to notify all developers that branding, which on top of it break things for other projects, in core is not or should not be allowed.

Ciao

Paolo

What a silly thread.

  Some neutral name for the integration should be picked and
implemented and/or both names be accepted; I would suggest 'lok'
for LibreOfficeKit. Commit/revert wars are a nonsense that helps
no-one - I would expect the ESC should intervene and cut out the
politics.

  There are of course three big problems in computer science:
naming things, and off-by-one errors - so it's no real surprise.

I guess it's hard to spot a cool among many lool but then
we'll have to notify all developers...

  LibreOffice is much cooler than you think; cf. the appended.

    Michael.

$ git grep lool
i18npool/source/localedata/data/om_ET.xml: <DefaultFullName>Onkoloolessa </DefaultFullName>

$ git grep cool
canvas/workben/canvasdemo.cxx: //TODO: do something cool
extras/source/autocorr/lang/en-AU/DocumentList.xml: <block-list:block block-list:abbreviated-name="shcool" block-list:name="school"/>
extras/source/autocorr/lang/en-GB/DocumentList.xml: <block-list:block block-list:abbreviated-name="shcool" block-list:name="school"/>
extras/source/autocorr/lang/en-US/DocumentList.xml: <block-list:block block-list:abbreviated-name="shcool" block-list:name="school"/>
extras/source/autocorr/lang/en-ZA/DocumentList.xml: <block-list:block block-list:abbreviated-name="shcool" block-list:name="school"/>
extras/source/autocorr/lang/ja/DocumentList.xml: <block-list:block block-list:abbreviated-name="shcool" block-list:name="school"/>
extras/source/autocorr/lang/ko/DocumentList.xml: <block-list:block block-list:abbreviated-name="shcool" block-list:name="school"/>
extras/source/autocorr/lang/zh-CN/DocumentList.xml: <block-list:block block-list:abbreviated-name="shcool" block-list:name="school"/>
extras/source/autocorr/lang/zh-TW/DocumentList.xml: <block-list:block block-list:abbreviated-name="shcool" block-list:name="school"/>
filter/source/svg/presentation_engine.js: window.webkit.messageHandlers.cool !== undefined)
filter/source/svg/presentation_engine.js: window.webkit.messageHandlers.cool.postMessage('EXITSLIDESHOW', '*');
oox/source/drawingml/shape3dproperties.cxx: case XML_coolSlant: return "coolSlant";
oox/source/token/tokens.txt:coolSlant
readlicense_oo/license/CREDITS.fodt: <text:p text:style-name="Table_20_Contents"><text:a xlink:type="simple" xlink:href="http://wiki.documentfoundation.org/User:Maahicool" text:style-name="Internet_20_link" text:visited-style-name="Visited_20_Internet_20_Link">Maahicool</text:a> (1) </text:p>
reportbuilder/java/org/libreoffice/report/pentaho/output/ImageProducer.java: // cool, the file exists. Let's try to read it.
sd/source/filter/html/htmlex.cxx: // Exceptions are cool...
sfx2/emojiconfig/emoji.json: "cool": {
sfx2/emojiconfig/emoji.json: "name": "squared cool",
sfx2/emojiconfig/emoji.json: "shortname": ":cool:",
solenv/inc/mime.types:x-conference/x-cooltalk ice
sw/source/core/doc/tblrwcl.cxx: // It *is* sometimes cool to have multiple tests/if's and assignments
sw/source/filter/ww8/ww8scan.cxx: Otherwise our cool fastsave algorithm can be brought to bear on the
sw/source/filter/ww8/ww8scan.cxx: //Store old end position for supercool new property finder that uses
vcl/unx/generic/print/common_gfx.cxx: // cool, we can concatenate rectangles
writerfilter/source/dmapper/TextEffectsHandler.cxx: case NS_ooxml::LN_ST_BevelPresetType_coolSlant: return "coolSlant";
writerfilter/source/ooxml/model.xml: <value>coolSlant</value>
writerfilter/source/ooxml/model.xml: <value tokenid="ooxml:Value_drawingml_ST_BevelPresetType_coolSlant">coolSlant</value>
writerfilter/source/ooxml/model.xml: <value>coolSlant</value>
writerfilter/source/ooxml/model.xml: <value tokenid="ooxml:ST_BevelPresetType_coolSlant">coolSlant</value>

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

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

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

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

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

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

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

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

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

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

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

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

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

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