Merging Of Contributions

Board Discuss
#1

Hello all,

I wonder what is the usual time slot it needs to merge a reviewed and
ready patch into the LibreOffice repository.

It would be great, if the board could share it's opinion. It's important
for new and other volunteer contributors to get some estimation on this.

Thanks in advance for your answer.

Regards,
Andreas

#2

Hi Andreas,

Andreas Mantke wrote:

I wonder what is the usual time slot it needs to merge a reviewed
and ready patch into the LibreOffice repository.

Answering as a developer here (and not as board member) - I think you
will get better answers & suggestions what to do, on the LibreOffice
developer list, or on IRC (see [1] for details).

Please also include a link to your concrete submission, so people can
jump right in.

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

Cheers,

-- Thorsten

#3

Hi Thorsten, hi all,

Hi Andreas,

Andreas Mantke wrote:

I wonder what is the usual time slot it needs to merge a reviewed
and ready patch into the LibreOffice repository.

Answering as a developer here (and not as board member) - I think you
will get better answers & suggestions what to do, on the LibreOffice
developer list, or on IRC (see [1] for details).

Please also include a link to your concrete submission, so people can
jump right in.

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

I wonder if it is useful to open a second (or more than that)
communication channel for this with Gerrit for code review (with an
email messaging) in place. I thought that Gerrit has been set up to make
the communication about patches more easy and help (volunteer)
developers. But maybe that's not intended with that project resource.

Regards,
Andreas

#4

Hi Andreas,

Hi Thorsten, hi all,

Hi Andreas,

Andreas Mantke wrote:

I wonder what is the usual time slot it needs to merge a reviewed
and ready patch into the LibreOffice repository.

Answering as a developer here (and not as board member) - I think you
will get better answers & suggestions what to do, on the LibreOffice
developer list, or on IRC (see [1] for details).

Please also include a link to your concrete submission, so people can
jump right in.

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

I wonder if it is useful to open a second (or more than that)
communication channel for this with Gerrit for code review (with an
email messaging) in place. I thought that Gerrit has been set up to make
the communication about patches more easy and help (volunteer)
developers. But maybe that's not intended with that project resource.

I'm not a developer so I probably cannot help directly but I'm interested to know what issues you are experiencing.

I kind of understand you have submitted a patch to fix an issue and you are waiting for it to be merged.

Is the waiting caused by the patch itself that has something wrong, the tooling or simply someone has been busy and it hasn't been reviewed yet?

Sorry for probably asking silly questions but having more details might help me and others understand how to avoid that issue.

Regards,
Andreas

Ciao

Paolo

#5

Hi Paolo,

Hi Andreas,

I wonder if it is useful to open a second (or more than that)
communication channel for this with Gerrit for code review (with an
email messaging) in place. I thought that Gerrit has been set up to make
the communication about patches more easy and help (volunteer)
developers. But maybe that's not intended with that project resource.

I'm not a developer so I probably cannot help directly but I'm
interested to know what issues you are experiencing.

I kind of understand you have submitted a patch to fix an issue and
you are waiting for it to be merged.

yes.

Is the waiting caused by the patch itself that has something wrong,
the tooling or simply someone has been busy and it hasn't been
reviewed yet?

The patch was reviewed by Jenkins and marked by a developer with +2 and
is marked ready to be merged.

Sorry for probably asking silly questions but having more details
might help me and others understand how to avoid that issue.

I think there are no silly questions.  Hope my answer helps to better
understand the situation.

Regards,
Andreas

#6

I wonder what is the usual time slot it needs to merge a reviewed and
ready patch into the LibreOffice repository.

https://dashboard.documentfoundation.org/app/kibana#/dashboard/Gerrit-Timing and
https://dashboard.documentfoundation.org/app/kibana#/dashboard/Gerrit-Backlog
have average and median timing metrics per repo and developer, and one
can tweak the filter to add the desired conditions. For more complex queries
you can use the elasticsearch API, but if there is interest in adding more
visuals to the dashboard we can also do that of course.

It would be great, if the board could share it's opinion.

An opinion on how to compute an average from existing data? I'm
confused.

#7

Hi Andreas,

Hi Paolo,

Hi Andreas,

I wonder if it is useful to open a second (or more than that)
communication channel for this with Gerrit for code review (with an
email messaging) in place. I thought that Gerrit has been set up to make
the communication about patches more easy and help (volunteer)
developers. But maybe that's not intended with that project resource.

I'm not a developer so I probably cannot help directly but I'm
interested to know what issues you are experiencing.

I kind of understand you have submitted a patch to fix an issue and
you are waiting for it to be merged.

yes.

Is the waiting caused by the patch itself that has something wrong,
the tooling or simply someone has been busy and it hasn't been
reviewed yet?

The patch was reviewed by Jenkins and marked by a developer with +2 and
is marked ready to be merged.

OK so if it's ready to be merged what is stopping it from happening?

Sorry for probably asking silly questions but having more details
might help me and others understand how to avoid that issue.

I think there are no silly questions.  Hope my answer helps to better
understand the situation.

Sorry but it kind of made it more difficult to understand for me.

You seem to say that it's all fine and ready to go but then something is still not right.

Is there an issue with merging patches in general or with merging patches related to specific components?

Can you share a link to it so that maybe someone looks at it and spots the issue?

Regards,
Andreas

Ciao

Paolo

#8

Hi Paolo, all,

Hi Andreas,

Hi Paolo,

Hi Andreas,

I wonder if it is useful to open a second (or more than that)
communication channel for this with Gerrit for code review (with an
email messaging) in place. I thought that Gerrit has been set up to
make
the communication about patches more easy and help (volunteer)
developers. But maybe that's not intended with that project resource.

I'm not a developer so I probably cannot help directly but I'm
interested to know what issues you are experiencing.

I kind of understand you have submitted a patch to fix an issue and
you are waiting for it to be merged.

yes.

Is the waiting caused by the patch itself that has something wrong,
the tooling or simply someone has been busy and it hasn't been
reviewed yet?

The patch was reviewed by Jenkins and marked by a developer with +2 and
is marked ready to be merged.

OK so if it's ready to be merged what is stopping it from happening?

I don't know. There is no message on Gerrit or somewhere else about an
issue which hinders merging.

Sorry for probably asking silly questions but having more details
might help me and others understand how to avoid that issue.

I think there are no silly questions.  Hope my answer helps to better
understand the situation.

Sorry but it kind of made it more difficult to understand for me.

You seem to say that it's all fine and ready to go but then something
is still not right.

Is there an issue with merging patches in general or with merging
patches related to specific components?

Can you share a link to it so that maybe someone looks at it and spots
the issue?

It is this patch (only a small one with two lines of code):

https://gerrit.libreoffice.org/c/core/+/138884

Regards,
Andreas

#9

Hi all,

I think it is about this patch:
https://gerrit.libreoffice.org/c/core/+/138884
It has a +2 from Adolfo Jayme Barrientos but is not yet submitted.

Kind regards,
Regina

#10

Given TDF separates administrative and technical responsibilities between the Board and ESC respectively, I am unclear why this matter is being raised here - has it already been raised at ESC without a resolution? Can someone explain please?

Cheers

Simon

On Thu, Sep 1, 2022 at 3:37 PM Andreas Mantke <maand@gmx.de> wrote:

Hi Thorsten, hi all,

Am 31.08.22 um 21:28 schrieb Thorsten Behrens:

Hi Andreas,

Andreas Mantke wrote:

I wonder what is the usual time slot it needs to merge a reviewed
and ready patch into the LibreOffice repository.

Answering as a developer here (and not as board member) - I think you
will get better answers & suggestions what to do, on the LibreOffice
developer list, or on IRC (see [1] for details).

Please also include a link to your concrete submission, so people can
jump right in.

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

I wonder if it is useful to open a second (or more than that)
communication channel for this with Gerrit for code review (with an
email messaging) in place. I thought that Gerrit has been set up to make
the communication about patches more easy and help (volunteer)
developers. But maybe that’s not intended with that project resource.

Regards,
Andreas

–

Free Software Advocate

Plone add-on developer

My blog: http://www.amantke.de/blog

–
To unsubscribe e-mail to: board-discuss+unsubscribe@documentfoundation.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.documentfoundation.org/www/board-discuss/
Privacy Policy: https://www.documentfoundation.org/privacy

–

#11

Hi Guilhem,

I wonder what is the usual time slot it needs to merge a reviewed and
ready patch into the LibreOffice repository.

https://dashboard.documentfoundation.org/app/kibana#/dashboard/Gerrit-Timing and
https://dashboard.documentfoundation.org/app/kibana#/dashboard/Gerrit-Backlog
have average and median timing metrics per repo and developer, and one
can tweak the filter to add the desired conditions. For more complex queries
you can use the elasticsearch API, but if there is interest in adding more
visuals to the dashboard we can also do that of course.

thanks for your explanation and the links.

Regards,
Andreas

#12

Hi Andreas,

On 01/09/2022 17:36, Andreas Mantke wrote:

It is this patch (only a small one with two lines of code):

https://gerrit.libreoffice.org/c/core/+/138884

I see a comment “The correct naming for LibreOffice is lool”

and a request to change a variable ending with cool into lool in LibreOffice core.

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.

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?

Regards,
Andreas

Ciao

Paolo

#13

Hi Simon,

I think, a large delay between review and submit is not a technical problem, but it needs a person who is responsible for an overview.
A technical problem is to provide a tool for a quick overview. However, the dashboard-links from Guilhem look promising.

A large delay is frustrating for the volunteer contributor and is contrary to a welcome culture.

Kind regards
Regin

#14

Hi Paolo, all,

Hi Andreas,

It is this patch (only a small one with two lines of code):

https://gerrit.libreoffice.org/c/core/+/138884

I see a comment "The correct naming for LibreOffice is lool"

and a request to change a variable ending with cool into lool in
LibreOffice core.

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.

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.

Regards,
Andreas

#15

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

–

#16

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

#17

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

#18

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

#19

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

#20

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>

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