RE: API doc on web site [Was: Accessing the comment object (annotation) in Draw/Impress via API]
Hello Peter, > -Original Message- > From: Peter Kovacs [mailto:pe...@apache.org] > Sent: Sunday, October 17, 2021 11:18 PM > To: dev@openoffice.apache.org > Subject: Re: API doc on web site [Was: Accessing the comment > object (annotation) in Draw/Impress via API] > The API Documentation is extracted from the Code. > > For example the comment in > > http://opengrok.openoffice.org/xref/aoo41x/main/offapi/com/sun > /star/modules.idl?r=d1766043#83 > > does have an impact on the web page: > > https://www.openoffice.org/api/docs/common/ref/com/sun/star/of > fice/module-ix.html > > I hope you see both documentations are linked. So when do we > update the > documentation on the web site? > > Currently we will never update the web site, and the danger > is that if > we change a comment in the documentation it will not end up > on the website.. > > So Arrigos Idea is to update with each release. This would keep the > documentation on the web in sync with the latest Code > released for this > API Version (Which should roughly correspond with the major release). > > It makes sense to publish on the website which Code the > extraction has > been taken from and what Versions the Documentation relates to. > > On an API Change, QA and documentation Versions need to be > discussed. yes, exactly. > But we can discuss this when we get near to a API Change. I > think until > then we have done some steps in respect of QA. How do you come to this hope, so we can all see that there is no regulated QA for years? Basically there is no real QA since Raphael left the project. That's just a description of the situation, because we lack enough volunteers to build up a really sufficient QA. But volunteers have to be motivated and for this we have to recognize performance and not admit people to the PMC according to personal preference (called alleged "merit"), but only according to performance. For example, we should have discussed honestly and factually how it came to the release mikt the (so-called) 'Big Sur Bug', to improve our release procedures, that such gross errors no longer occur. But nothing happened. '9 years as a top level project' ... well, I've been in the OO project for more than 16 years ... Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: API doc on web site [Was: Accessing the comment object (annotation) in Draw/Impress via API]
Hello All, replying to myself as a correction. On Thu, Oct 14, 2021 at 07:08:25PM +0200, Arrigo Marchiori wrote: [...] > Those pages should be generated by Autodoc, for what I understand. > > Are there any scripts that do this? Or any policies on how and when to > update the API documentation? For example, I would suggest that each > new release would be a good time to update the API. I should have written "API documentation" instead of API. I apologize. I agree that changing the API is a ``big thing'', that we shall be very careful, and I understand Jörg's and Marcus' concern while reading my paragraph above! I suggest we update the _documentation_ whenever possible because IMHO that can be helpful for developers. I hope I could clarify my proposal now. Best regards, -- Arrigo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: API doc on web site [Was: Accessing the comment object (annotation) in Draw/Impress via API]
Hi Jörg, On 17.10.21 19:48, Jörg Schmidt wrote: Hello Peter, -Original Message- From: Peter Kovacs [mailto:pe...@apache.org] Sent: Sunday, October 17, 2021 11:27 AM To: dev@openoffice.apache.org Subject: Re: API doc on web site [Was: Accessing the comment object (annotation) in Draw/Impress via API] Hi Jörg, I am not sure what you refer to. I refer to the fact that changes in the API documentation are marked in time (the typical entry is "since ..."), so that the API documentation can be used in practice for all program versions. I think we are on the same page if we want to change the API, but I think this is not the topic. The documentation has no influence on backward compatibility. right. What I am referring to is only that we should not make changes if the QA is not 100% guaranteed. And what I currently experience is that there is a tiny(!) problem in the API documentation, but immediately demanded now to regularly renew the documentation routinely. Again this is relevant if we change the API itself. Explain to me bitterly where there are at all changes in the API that would make it necessary to update the documentation inflationary frequently? I follow every release carefully, only from API changes I have not noticed for years. The API Documentation is extracted from the Code. For example the comment in http://opengrok.openoffice.org/xref/aoo41x/main/offapi/com/sun/star/modules.idl?r=d1766043#83 does have an impact on the web page: https://www.openoffice.org/api/docs/common/ref/com/sun/star/office/module-ix.html I hope you see both documentations are linked. So when do we update the documentation on the web site? Currently we will never update the web site, and the danger is that if we change a comment in the documentation it will not end up on the website.. So Arrigos Idea is to update with each release. This would keep the documentation on the web in sync with the latest Code released for this API Version (Which should roughly correspond with the major release). It makes sense to publish on the website which Code the extraction has been taken from and what Versions the Documentation relates to. On an API Change, QA and documentation Versions need to be discussed. But we can discuss this when we get near to a API Change. I think until then we have done some steps in respect of QA. Carl is working on improvements, and I would like to try if we can establish a UI check with UI Path or similar tool. All the best Peter -- This is the Way! http://www.apache.org/theapacheway/index.html - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Happy Anniversary (9 years as TLP)
On Sun, Oct 17, 2021 at 06:41:31PM +0200, Andrea Pescetti wrote: > On 17/10/2021 Matthias Seidel wrote: > > On this day, 9 years ago Apache OpenOffice became an Apache Top Level > > Project (TLP). > > Thanks for the reminder... and a big thank you to those who still ensure the > continued success of OpenOffice! +1 Happy anniversary! :-) -- Arrigo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: API doc on web site [Was: Accessing the comment object (annotation) in Draw/Impress via API]
Hello Peter, > -Original Message- > From: Peter Kovacs [mailto:pe...@apache.org] > Sent: Sunday, October 17, 2021 11:27 AM > To: dev@openoffice.apache.org > Subject: Re: API doc on web site [Was: Accessing the comment > object (annotation) in Draw/Impress via API] > > Hi Jörg, > > > I am not sure what you refer to. I refer to the fact that changes in the API documentation are marked in time (the typical entry is "since ..."), so that the API documentation can be used in practice for all program versions. > The documentation has no > influence on > backward compatibility. right. What I am referring to is only that we should not make changes if the QA is not 100% guaranteed. And what I currently experience is that there is a tiny(!) problem in the API documentation, but immediately demanded now to regularly renew the documentation routinely. Explain to me bitterly where there are at all changes in the API that would make it necessary to update the documentation inflationary frequently? I follow every release carefully, only from API changes I have not noticed for years. > It would be beneficial if we update the documentation > with each release, > allowing a process that the documentation improves. And where is this process? What I see is that we don't even have a regulated QA for the program. Why do you want to make more work for which quality assurance never has the time? > I would not see documentation update as a blocker to a release thought. Neither do I in the least, but that's not the point, it's the quality assurance of the API documentation. Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Happy Anniversary (9 years as TLP)
On 17/10/2021 Matthias Seidel wrote: On this day, 9 years ago Apache OpenOffice became an Apache Top Level Project (TLP). Thanks for the reminder... and a big thank you to those who still ensure the continued success of OpenOffice! Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Happy Anniversary (9 years as TLP)
I thank them all, too. Regards, Jürgen Am 17.10.2021 um 12:04 schrieb Matthias Seidel: Hi all, On this day, 9 years ago Apache OpenOffice became an Apache Top Level Project (TLP). Thanks to all the volunteers who made that happen and spent their private time since then! Regards, Matthias - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[GitHub] [openoffice] leginee commented on pull request #122: Address bug 128356 and similar ones (duplicated XML attributes)
leginee commented on pull request #122: URL: https://github.com/apache/openoffice/pull/122#issuecomment-945085618 Sure. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[GitHub] [openoffice] Pilot-Pirx commented on pull request #122: Address bug 128356 and similar ones (duplicated XML attributes)
Pilot-Pirx commented on pull request #122: URL: https://github.com/apache/openoffice/pull/122#issuecomment-945085404 With the code now in trunk, do we want to start testing it? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[GitHub] [openoffice] leginee edited a comment on pull request #122: Address bug 128356 and similar ones (duplicated XML attributes)
leginee edited a comment on pull request #122: URL: https://github.com/apache/openoffice/pull/122#issuecomment-945085021 Sorry, I forgot about it. I wanted to run the code once. I note in my review the state I have. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[GitHub] [openoffice] leginee commented on pull request #122: Address bug 128356 and similar ones (duplicated XML attributes)
leginee commented on pull request #122: URL: https://github.com/apache/openoffice/pull/122#issuecomment-945085021 Sorry, I forgot about it. I wanted to run the code once. The code change itself looked fine, from code review perspective. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Happy Anniversary (9 years as TLP)
Hi all, On this day, 9 years ago Apache OpenOffice became an Apache Top Level Project (TLP). Thanks to all the volunteers who made that happen and spent their private time since then! Regards, Matthias smime.p7s Description: S/MIME Cryptographic Signature
Re: ZLIB
Hi Peter, Am 17.10.21 um 11:33 schrieb Peter Kovacs: > Hi Matrthias, > > Can you post the Error from the buiild? I will try... Basically it is MSVC 2008 (EOL since 2018) complaining about deprecated code in ZLIB. Of course It builds, somehow... ;-) Regards, Matthias > > Thanks > > All the best > > Peter > > On 03.10.21 22:00, Matthias Seidel wrote: >> Hi all, >> >> bumping this one up because I just got an error while building on >> Windows complaining about zlib. >> >> I don't know if that is a real problem now (I just started the build >> again) but it would be great if we could update this ancient piece of >> software. >> >> Regards, >> >> Matthias >> >> Am 11.04.21 um 19:20 schrieb Matthias Seidel: >>> Hi Marcus, >>> >>> Am 11.04.21 um 19:07 schrieb Marcus: Am 11.04.21 um 18:22 schrieb Matthias Seidel: > [...] > > Our ZLIB is 1.2.7 from 2012. > The most recent version is 1.2.11 from 2017 [1]. > > Time to update? yes, starting the update on trunk would show how good the idea was. ;-) >>> If even an outdated compiler like MSVC 2008 already complains about >>> deprecated code it may be time! >>> >>> But it has to be done by someone else... ;-) >>> >>> Matthias >>> Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org smime.p7s Description: S/MIME Cryptographic Signature
Re: ZLIB
Hi Matrthias, Can you post the Error from the buiild? Thanks All the best Peter On 03.10.21 22:00, Matthias Seidel wrote: Hi all, bumping this one up because I just got an error while building on Windows complaining about zlib. I don't know if that is a real problem now (I just started the build again) but it would be great if we could update this ancient piece of software. Regards, Matthias Am 11.04.21 um 19:20 schrieb Matthias Seidel: Hi Marcus, Am 11.04.21 um 19:07 schrieb Marcus: Am 11.04.21 um 18:22 schrieb Matthias Seidel: [...] Our ZLIB is 1.2.7 from 2012. The most recent version is 1.2.11 from 2017 [1]. Time to update? yes, starting the update on trunk would show how good the idea was. ;-) If even an outdated compiler like MSVC 2008 already complains about deprecated code it may be time! But it has to be done by someone else... ;-) Matthias Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- This is the Way! http://www.apache.org/theapacheway/index.html - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: API doc on web site [Was: Accessing the comment object (annotation) in Draw/Impress via API]
Hi Jörg, I am not sure what you refer to. The documentation has no influence on backward compatibility. According to current rules for Version numbers we must bump the first digit if we do an API change. So for Version 5 we must provide a Documentation a Version 4 Documentation and a Version 5 Documentation. I think even if Version 5 is backward compatible with Version 4, the documentation should be per Main Version. I am fighting that we stick to the rule. (Actually I whish we only change the first Digit if we have an API change. Which is a clear signal to anyone what he has to look out for. Current rules have a loophole to bumb for a majore release for features. Which I do not see the benefit in. But this is maybe a different discussion) It would be beneficial if we update the documentation with each release, allowing a process that the documentation improves. I think that means at current release speed we update API Documentation once / twice a year. Which should not be to much effort? I would not see documentation update as a blocker to a release thought. Maybe even not part on the Release itself. But I think it is smart to have both process in sync. I think Arrigos Idea is a good one. All the best Peter On 15.10.21 10:15, Jörg Schmidt wrote: -Original Message- From: Arrigo Marchiori [mailto:ard...@yahoo.it.INVALID] Sent: Thursday, October 14, 2021 7:08 PM To: dev@openoffice.apache.org Subject: API doc on web site [Was: Accessing the comment object (annotation) in Draw/Impress via API] the API doc is (somehow) part of the website. And what you are looking for is maybe here: https://github.com/apache/openoffice-org/blob/main/part2/conte nt/api/docs/common/ref/com/sun/star/office/module-ix.html Thank you! That is what I meant. Those pages should be generated by Autodoc, for what I understand. Are there any scripts that do this? Or any policies on how and when to update the API documentation? For example, I would suggest that each new release would be a good time to update the API. -1 (for the moment) this is only a good idea if there was a way to make backward compatibility, because information is needed for all OO versions, not only for the current version please understand me correctly: it's not about not changing anything, it's about not changing a whole procedure without careful(!) examination just because there is an incorrect entry Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- This is the Way! http://www.apache.org/theapacheway/index.html - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
