Re: API doc on web site [Was: Accessing the comment object (annotation) in Draw/Impress via API]
Hi Jörg, Check: Version Number Assignment (Apache OpenOffice internal) Structure .. Explanation : huge release with visible changes and new features including incompatible API changes if necessary. Translation updates are most often necessary to address the UI visible changes. : smaller improvements of features that don't need any translation. And of course any kind of bug fixes. : only selected bug fixes and most often only critical ones. This includes any potential security issues. From: https://cwiki.apache.org/confluence/display/OOOUSERS/Releases That is the current policy. So well as long as compatible we could Change the API with a minor Release. It seems I got the detail wrong. All the best Peter On 19.10.21 15:30, Jörg Schmidt wrote: Hello Carl, -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Tuesday, October 19, 2021 1:13 PM To:dev@openoffice.apache.org Subject: Re: API doc on web site [Was: Accessing the comment object (annotation) in Draw/Impress via API] Actually we do provide updated documentation included in the SDK with each convenience binary release. It can be found on Linux at /opt/openoffice4/sdk/docs/common/ref/module-ix.html if the SDK is installed. Knowing that we can't make API changes like adding or deprecating methods or things like that in a minor version change, Is this a principle that _all_ those involved in releases will also _reliably_ follow? It's up to us to inform new contributors who may make such a mistake if it were to happen. yes, but ... As far as I know, only the PMC has the right to decide about the release of a release - so will the PMC reliably support the mentioned principle (='API changes not in a minor release')? I would appreciate a clear "yes" or "no" on this. And please allow me to say that the current formal minor release of AOO is "4.1", so, respecting the implied principle, a change to the API is thus not allowed until version 5.0.0. greetings, 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
QA automatisation in AOO
Hello all, In the discussion on API, and releases Jörg has ask about how we could improve QA. The only way in general is to formalize. We need to define testcases and automate those. There are 2 ways of Automation: 1) is through Code 2) is through GUI. Today both can be automated. @1) The Automation through code is already in place, but needs optimization and improvements. We lack KPIs like test coverage, We lack a reporting facility and we have issues during the build. @2) What we have are test cases written on [1]. What we need is to extend them. And then we need to automate them to get a good test coverage. Also in this field we have no statistics. I think the last volunteer looked into it has been Kai 3 years ago. I am not aware that we have anyone who is looking into it now. We have also a lot of Testcases in Bugzilla. Also some years ago Mechtilde and I looked at some Test tool for Testers. But we did not come to any conclusion. Once we have testcases, we can again Automate them. These Tools are called Robots, and remember in some ways in game bots. They click on the Application window and check for results. There are open sourced solution and Commercial solutions with community editions. That is what I have in mind when I talk in QA. -- 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: Compatibility of new releases with older operating systems
Dear Dave, All, thank you for all the replies to this thread. On Tue, Oct 05, 2021 at 03:58:32PM -0700, Dave Fisher wrote: > We have these pages: > https://www.openoffice.org/dev_docs/source/sys_reqs_aoo40.html [...] I understand there are plenty of "minimum system requirements" scattered around the web site. I was looking for something more developer-oriented. I made an attempt here: https://cwiki.apache.org/confluence/display/OOOUSERS/Target+System+Requirements I think that the other pages miss information about glibc and C and C++ standards, that are very important when dealing with external libraries (such as the latest expat upgrade). I am not happy to add another page to the big number of existing ones, so I am open to suggestions about wich of the existing pages shall rather incorporate that information. I also ask other ``C and C++ proficient'' people here to kindly check that the data on the page is accurate. Best regards, -- Arrigo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Project Planning page on cwiki
Dear dev@, this may have been raised many other times... but why do we keep publishing release notes under the "Project Planning" cwiki page [1] when that page starts with a big warning that is only for the incubation phase? :-) My humble suggestion, given the fact that the section contains updated information, is to create a subpage "Incubation" and then move under it all subpages related to the incubation period. I am available to do this work, if no one else has either better ideas or good reasons not to do so. [1]: https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning Thank you in advance, -- Arrigo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Project Planning page on cwiki
On 24.10.21 16:13, Arrigo Marchiori wrote: Dear dev@, Hi! this may have been raised many other times... but why do we keep publishing release notes under the "Project Planning" cwiki page [1] when that page starts with a big warning that is only for the incubation phase? :-) I think there are a lot of old an new stuff intermixed. We have left the existing stuff as is and added the new stuff. My humble suggestion, given the fact that the section contains updated information, is to create a subpage "Incubation" and then move under it all subpages related to the incubation period. I am available to do this work, if no one else has either better ideas or good reasons not to do so. Sounds like an improvement. I have no objection. :) [1]: https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning -- 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: QA automatisation in AOO
Hello, > -Original Message- > From: Peter Kovacs [mailto:pe...@apache.org] > Sent: Sunday, October 24, 2021 2:32 PM > To: dev@openoffice.apache.org > Subject: QA automatisation in AOO > > Hello all, > > In the discussion on API, and releases Jörg has ask about how > we could > improve QA. > > The only way in general is to formalize. We need to define > testcases and > automate those. That sounds good, but we need specifications to define test cases. Not all tests have to run automatically (e.g. an installation test is more likely to be done manually), but it has to be defined what the minimum requirements are - that's what I mean by specifications. > What we have are test cases written on [1]. Can you please post a link to this (or what does "[1]" mean?) greetings, Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: QA automatisation in AOO
Hi, On 24.10.21 20:39, Jörg Schmidt wrote: Hello, -Original Message- From: Peter Kovacs [mailto:pe...@apache.org] Sent: Sunday, October 24, 2021 2:32 PM To: dev@openoffice.apache.org Subject: QA automatisation in AOO Hello all, In the discussion on API, and releases Jörg has ask about how we could improve QA. The only way in general is to formalize. We need to define testcases and automate those. That sounds good, but we need specifications to define test cases. Not all tests have to run automatically (e.g. an installation test is more likely to be done manually), but it has to be defined what the minimum requirements are - that's what I mean by specifications. Well, no one will stop anyone to execute the test cases. What we have are test cases written on [1]. Can you please post a link to this (or what does "[1]" mean?) Sorry, forgot to add the link. [1] https://www.openoffice.org/qa/testcase/index.html But note: these are the onbes I am aware of. Checkout the Mail that announced it: https://lists.apache.org/thread.html/dad44868cf67a2ad627a0c27fde213e69cc3b6dfd8617e55e553%40%3Cdev.openoffice.apache.org%3E greetings, 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
RE: API doc on web site [Was: Accessing the comment object (annotation) in Draw/Impress via API]
> -Original Message- > From: Peter Kovacs [mailto:pe...@apache.org] > Sent: Sunday, October 24, 2021 2:19 PM > 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, > > Check: > > > Version Number Assignment (Apache OpenOffice internal) > > > Structure > > .. > > > Explanation > > : huge release with visible changes and new features including > incompatible API changes if necessary. Translation updates are most > often necessary to address the UI visible changes. > > : smaller improvements of features that don't need any > translation. And of course any kind of bug fixes. > > : only selected bug fixes and most often only critical > ones. This > includes any potential security issues. > > From: https://cwiki.apache.org/confluence/display/OOOUSERS/Releases Yes, agreed. > That is the current policy. So well as long as compatible we could > Change the API with a minor Release. I see no need and no justification for watering down clear rules/explanations. The question of what "compatible" actually means is by no means easy to answer. Example: Perhaps there is a property, method, etc. in the API that accidentally has a spelling mistake in its name (I recently had something like this in LO regarding a parameter of a Posgresql access) - on the one hand, one can then argue that a name correction that does not change the actual function would be compatible, but one can also argue that it is incompatible because only the old naming (which is possibly already used a lot in projects) no longer works. greetings, Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: QA automatisation in AOO
Hi, I am developing an infra for QA. Initially aimed for accessibility, I think the whole community can use this: they are based on Dogtail and track events from at-spi, on Linux, that enables to see if a key press or a mouse mouvement has the appropriate feedback from an event point of view. Perhaps it may be ported to other platforms. Anyway, I now have a high database for Writer scenarios. I can help providing such scenarios, translating those I created (there are several hunderds of them). Just need a wiki for this or something like this. If you want the example of usage of dogtail, see https://people.debian.org/~jpmengual/test.tar.gz Writer has already scenarios coded for LO 4.2, because it worked from an accessibilit piont of view, but these can be ported. Regards Le 24/10/2021 à 20:47, Peter Kovacs a écrit : Hi, On 24.10.21 20:39, Jörg Schmidt wrote: Hello, -Original Message- From: Peter Kovacs [mailto:pe...@apache.org] Sent: Sunday, October 24, 2021 2:32 PM To: dev@openoffice.apache.org Subject: QA automatisation in AOO Hello all, In the discussion on API, and releases Jörg has ask about how we could improve QA. The only way in general is to formalize. We need to define testcases and automate those. That sounds good, but we need specifications to define test cases. Not all tests have to run automatically (e.g. an installation test is more likely to be done manually), but it has to be defined what the minimum requirements are - that's what I mean by specifications. Well, no one will stop anyone to execute the test cases. What we have are test cases written on [1]. Can you please post a link to this (or what does "[1]" mean?) Sorry, forgot to add the link. [1] https://www.openoffice.org/qa/testcase/index.html But note: these are the onbes I am aware of. Checkout the Mail that announced it: https://lists.apache.org/thread.html/dad44868cf67a2ad627a0c27fde213e69cc3b6dfd8617e55e553%40%3Cdev.openoffice.apache.org%3E greetings, Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - 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]
On 24.10.21 20:57, Jörg Schmidt wrote: -Original Message- From: Peter Kovacs [mailto:pe...@apache.org] Sent: Sunday, October 24, 2021 2:19 PM 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, Check: Version Number Assignment (Apache OpenOffice internal) Structure .. Explanation : huge release with visible changes and new features including incompatible API changes if necessary. Translation updates are most often necessary to address the UI visible changes. : smaller improvements of features that don't need any translation. And of course any kind of bug fixes. : only selected bug fixes and most often only critical ones. This includes any potential security issues. From: https://cwiki.apache.org/confluence/display/OOOUSERS/Releases Yes, agreed. That is the current policy. So well as long as compatible we could Change the API with a minor Release. I see no need and no justification for watering down clear rules/explanations. The question of what "compatible" actually means is by no means easy to answer. Example: Perhaps there is a property, method, etc. in the API that accidentally has a spelling mistake in its name (I recently had something like this in LO regarding a parameter of a Posgresql access) - on the one hand, one can then argue that a name correction that does not change the actual function would be compatible, but one can also argue that it is incompatible because only the old naming (which is possibly already used a lot in projects) no longer works. I define Incompatible on User API level if the API user has to change his work, as a result of changes in a release. -- 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: QA automatisation in AOO
Hi! On 24.10.21 21:27, MENGUAL Jean-Philippe wrote: Hi, I am developing an infra for QA. Initially aimed for accessibility, I think the whole community can use this: they are based on Dogtail and track events from at-spi, on Linux, that enables to see if a key press or a mouse mouvement has the appropriate feedback from an event point of view. Perhaps it may be ported to other platforms. Anyway, I now have a high database for Writer scenarios. I can help providing such scenarios, translating those I created (there are several hunderds of them). Just need a wiki for this or something like this. If you want the example of usage of dogtail, see https://people.debian.org/~jpmengual/test.tar.gz Writer has already scenarios coded for LO 4.2, because it worked from an accessibilit piont of view, but these can be ported. If you are fine with a wiki page, do you have an MWiki Account? If not request one by sending a mail to dev list. We need the email address you want to be associated with and a nickname. (Use a specific Subject like "MWiki account needed" so we are aware on the need.) I found a section for QA Test Automation at [1], which is interesting for all that are interested in QA. As a starting point I added [2] for test cases with dogtails. Feel free to use the page or create additional pages. HTH All the best Peter [1] https://wiki.openoffice.org/wiki/QA/test_automation [2] https://wiki.openoffice.org/wiki/QA/dogtail -- 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: QA automatisation in AOO
Hi Peter and All, On 10/24/21 2:47 PM, Peter Kovacs wrote: Hi, On 24.10.21 20:39, Jörg Schmidt wrote: Hello, -Original Message- From: Peter Kovacs [mailto:pe...@apache.org] Sent: Sunday, October 24, 2021 2:32 PM To: dev@openoffice.apache.org Subject: QA automatisation in AOO Hello all, In the discussion on API, and releases Jörg has ask about how we could improve QA. The only way in general is to formalize. We need to define testcases and automate those. That sounds good, but we need specifications to define test cases. Not all tests have to run automatically (e.g. an installation test is more likely to be done manually), but it has to be defined what the minimum requirements are - that's what I mean by specifications. Well, no one will stop anyone to execute the test cases. What we have are test cases written on [1]. Can you please post a link to this (or what does "[1]" mean?) Sorry, forgot to add the link. [1] https://www.openoffice.org/qa/testcase/index.html But note: these are the onbes I am aware of. Checkout the Mail that announced it: https://lists.apache.org/thread.html/dad44868cf67a2ad627a0c27fde213e69cc3b6dfd8617e55e553%40%3Cdev.openoffice.apache.org%3E I believe these were extracted from the old testlink system before we lost it. Many of these are included in the automated test suites as indicated by the automation script names on the individual pages. Not sure how many or what the coverage is and that would be good to know. Also as a source of a TODO list for volunteers. There are currently 867 functional tests and 49 build verification tests as well as performance tests that I haven't looked at yet. I'll also point out my current work on running the automated suites separate from the need to build the office in the standalone-test branch which I hope to merge sometime soon. I'd be happy to collaborate if anyone wants to help. We should move QA specific discussions to the QA list when the time comes. Best regards, Carl greetings, Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - 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]
> -Original Message- > From: Peter Kovacs [mailto:pe...@apache.org] > Sent: Sunday, October 24, 2021 9:42 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 question of what "compatible" actually means is by no > means easy to answer. > > > > Example: Perhaps there is a property, method, etc. in the > API that accidentally has a spelling mistake in its name (I > recently had something like this in LO regarding a parameter > of a Posgresql access) - on the one hand, one can then argue > that a name correction that does not change the actual > function would be compatible, but one can also argue that it > is incompatible because only the old naming (which is > possibly already used a lot in projects) no longer works. > > I define Incompatible on User API level if the API user has to change > his work, as a result of changes in a release. OK, but what helps and your (or my) definition? We need a definition that everyone recognises, especially the PMC because they have the power to decide on releases. But I repeat myself: your statements about major, minor and micro releases, and that API changes should only be made in major releases, make sense and are recognised (I think by everyone). So why should we want to violate them? greetings, Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
