Re: [QA AUTOMATION] Standalone Tests now available in standalone-test branch
Am 30.09.21 um 04:02 schrieb Carl Marcum: Just an FYI on the status of my work on allowing the automated test suites to compile and run tests without a working AOO build environment. I've started a new branch standalone-test [1] with a README file explaining the usage. [...] thanks for your work. That this test suite is now more modern but first of all usable with a fresh build AOO is a really great improvement. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Start working on AOO 4.1.11?
Am 14.05.21 um 17:44 schrieb Matthias Seidel: BTW, I have first Test builds for Windows available: https://home.apache.org/~mseidel/AOO-builds/AOO-4111-Test/ Nothing spectacular, but builds without problems. installs good, with a valid signature (special build from Matthias) now also without the big warning from Windows. Looks promising for future builds. And still with the warning message for bad hyperlinks. ;-) Marcus Am 14.05.21 um 07:14 schrieb Arrigo Marchiori: On Thu, May 13, 2021 at 09:06:32AM +0200, Marcus wrote: Am 13.05.21 um 07:50 schrieb Arrigo Marchiori: can someone please allow setting '4.1.11' as 'Target Milestone' on BugZilla? I would like to set it on https://bz.apache.org/ooo/show_bug.cgi?id=128453 done - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Start working on AOO 4.1.11?
Am 13.05.21 um 07:50 schrieb Arrigo Marchiori: can someone please allow setting '4.1.11' as 'Target Milestone' on BugZilla? I would like to set it on https://bz.apache.org/ooo/show_bug.cgi?id=128453 done marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [LAZY CONSENSUS] Merge PR-125 into 4.1.X branch
Am 11.04.21 um 20:58 schrieb Carl Marcum: Since this is a rather large pull request based on many commits I want to use lazy consensus here. This PR-125 [1] is based on a lot of work by Damjan and a few others on fixing flaky automated tests and other improvements that could be back-ported to the 4.1 line. Also included is a fix for the 3 FVT tests that hang waiting on the test runner to accept a dialog. As I run a lot of these tests I think these are useful to the 4.1 line. Everything is below the test directory so it should not affect any builds. Unless there are objections I plan to pull these in to the 4.1.X branch after 72 hours. [1] https://github.com/apache/openoffice/pull/125 please wait until the new release is done. We shouldn't do too many things at the same time on the same loction. Thanks Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Duplicate bugs: resolved vs closed
Am 15.02.21 um 07:01 schrieb Arrigo Marchiori: I see you changed the bug reports I set to "resolved duplicate", to "closed duplicate". I apologize for having marked them wrong in the first place... it was Bugzilla's default behavior so I just trusted it blindly. But "closed" makes more sense to me than "resolved" in fact. I will make sure I will do the right thing in the future. don't worry, no big issue. For "Duplicate" marked bugs there isn't any further feedback or action expected. Therefore we can transfer them to their end status which is always "Closed". So, I've just closed them. :-) Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Duplicate bugs: shall we follow strict chronological order?
Am 11.02.21 um 09:03 schrieb Arrigo Marchiori: I want to mark some duplicate bugs and I have a question. for your example, see comments inline. Suppose the bugs are numbered 2, 4, and 6. I have been working on number 4, because I did not know about number 2. For this reason, number 4 has more comments on BugZilla and my GitHub PR refers to it. I will declare that no. 6 is a duplicate, because it was reported afterwards. yes Can I indicate that no. 2 is a duplicate of no. 4 even if it was reported before, although according to a strict time-based logic it should be the opposite (i.e. that no. 4 is a duplicate of no. 2)? Yes The reason I believe it would be better to flag no. 2 as duplicated of no. 4 is because report no. 4 contains much more data about the problem and IMHO it should ``stand out'' with respect to the others. +1 In general: Following the chronological order is the right thing. This means the oldest issue will remain when all others are decribing the same problem. Exceptions (of course ;-)): The respective issue should survive when: - it has the most helpful comments - it already has a doc to reproduce the problem - it has already a reference to SVN / Git / GitHub ... - it has the most votes, or links to "see also" issues - it has in general most helpful data. That means chronological yes, but maybe it makes sense to use another issue when it is more helpful and then close all others as duplicate. Thank you in advance for your guidance, I hope this is helpful for you. That's the way I'm doing it. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Please add me to the "qa-team"
Am 20.10.2018 um 13:37 schrieb Andrea Pescetti: Luca Genova wrote: send a completly empty email to qa-subscribe No, let's avoid confusion. Hugo asked, correctly, to be added to the "qa team" in Bugzilla, which is a role in the Bugzilla account. This has nothing to do (from a technical point of view) with this mailing list. Hugo: nothing else to do besides the request you have already sent; Marcus or one of the Bugzilla administrators will add the requested role to your Bugzilla account. I've added the "qa-team", "canconfirm" and "editbugs" permissions to your BZ user account. Have fun Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Requesting to be added to bugzilla list "qa-team"
Am 27.12.2017 um 20:31 schrieb DurgaPrasad Potnuru: https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers email id for my jira CWiki account is pvvdurgapra...@gmail.com details to be added are: Name - V V Durgaprasad, Potnuru Home - Hyderabad, India Skills/ Interests - Documentation, QA thanks for the data. I've added you to the webpage. For an CWiki account please have a look here: https://cwiki.apache.org/confluence/display/OOOUSERS/Wiki+Home Marcus On Wed, Dec 27, 2017 at 4:16 PM, Marcus wrote: Am 27.12.2017 um 11:30 schrieb DurgaPrasad Potnuru: It does also help if my user can be added to list of volunteers in Jira for QA support and Documentation support. I did send communication requesting edit permission for that wiki page, guess it was also missed out due to holidays. Is it possible for you to check that .. sure, do you have link to the list? Thanks Marcus On Dec 27, 2017 15:41, "Marcus" wrote: Thanks for your offer to help. I've added your user to the "qa-team" in Bugzilla. PS: Please note that many of us volunteers are in the year end holidays. So, things are going more slowly than on other days. Marcus Am 26.12.2017 um 18:31 schrieb DurgaPrasad Potnuru: Any one there to help? If not able to assign me permission, please confirm this issue 127634 On Sun, Dec 24, 2017 at 10:41 AM, DurgaPrasad Potnuru < pvvdurgapra...@gmail.com> wrote: team, I am looking to volunteer for QA. to help me confirm defects, please add my user to "qa-team" list in bz. username: pvvdurgapra...@gmail.com - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Requesting to be added to bugzilla list "qa-team"
Am 27.12.2017 um 11:30 schrieb DurgaPrasad Potnuru: It does also help if my user can be added to list of volunteers in Jira for QA support and Documentation support. I did send communication requesting edit permission for that wiki page, guess it was also missed out due to holidays. Is it possible for you to check that .. sure, do you have link to the list? Thanks Marcus On Dec 27, 2017 15:41, "Marcus" wrote: Thanks for your offer to help. I've added your user to the "qa-team" in Bugzilla. PS: Please note that many of us volunteers are in the year end holidays. So, things are going more slowly than on other days. Marcus Am 26.12.2017 um 18:31 schrieb DurgaPrasad Potnuru: Any one there to help? If not able to assign me permission, please confirm this issue 127634 On Sun, Dec 24, 2017 at 10:41 AM, DurgaPrasad Potnuru < pvvdurgapra...@gmail.com> wrote: team, I am looking to volunteer for QA. to help me confirm defects, please add my user to "qa-team" list in bz. username: pvvdurgapra...@gmail.com - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Requesting to be added to bugzilla list "qa-team"
Thanks for your offer to help. I've added your user to the "qa-team" in Bugzilla. PS: Please note that many of us volunteers are in the year end holidays. So, things are going more slowly than on other days. Marcus Am 26.12.2017 um 18:31 schrieb DurgaPrasad Potnuru: Any one there to help? If not able to assign me permission, please confirm this issue 127634 On Sun, Dec 24, 2017 at 10:41 AM, DurgaPrasad Potnuru < pvvdurgapra...@gmail.com> wrote: team, I am looking to volunteer for QA. to help me confirm defects, please add my user to "qa-team" list in bz. username: pvvdurgapra...@gmail.com - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Access denied on Dictionaries page
Am 26.10.2017 um 23:24 schrieb Andrea Pescetti: Marcus wrote: Am 26.10.2017 um 22:23 schrieb Andrea Pescetti: If we see users confused by the "double update" process we will have to add an item to the Release Notes. I don't understand what you want to write to the release notes. I mean: if we start getting e-mails from people who say "I upgraded to version 4.1.4 and the upgrade failed since it still tells me that an update is available" then we should explain somewhere that the application updates and the dictionary updates are separate, and that it is expected that after upgrading to 4.1.4 you are notified that a newer English dictionary is available. If users actually read and understand messages, there will be no need for this. I think the most people don't read them and don't know that such is existing at all. So, we can add something to the relase notes but IMHO this won't change anything. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Access denied on Dictionaries page
Am 26.10.2017 um 22:23 schrieb Andrea Pescetti: On 26/10/2017 Marcus wrote: Am 26.10.2017 um 12:09 schrieb Marco A.G.Pinto: Now I get an access error in the official page: http://extensions.openoffice.org/en/project/english-dictionaries-apache-openoffice maybe a temporary outage in the second where you have looked. I've test now and it's working. Besides the problem itself (I confirm I see the page normally too) this means that people who upgrade to OpenOffice 4.1.4 will immediately see a notice saying they should update their English dictionary. This is quite annoying but there is nothing we can do about it right now. For the next version we should probably, like we did in the past, agree that the English dictionary does not get updated for at least one month after release. we could write to the usual mailing lists to ask for a 1 month break of updates. I'm pretty sure that Marco would support us. But others we don't know and when they don't write about their updates here, we won't reach. If we see users confused by the "double update" process we will have to add an item to the Release Notes. I don't understand what you want to write to the release notes. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Access denied on Dictionaries page
Am 26.10.2017 um 12:09 schrieb Marco A.G.Pinto: Hi Marco, Now I get an access error in the official page: http://extensions.openoffice.org/en/project/english-dictionaries-apache-openoffice Could someone take a look at it? maybe a temporary outage in the second where you have looked. I've test now and it's working. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Request to be added to Bugzilla
Am 12/17/2016 06:08 PM, schrieb jakob.jawor...@t-online.de: my Bugzilla username is jakob.jawor...@t-online.de <mailto:jakob.jawor...@t-online.de> thanks for adding me to Bugzilla. I've added you to the groups "qa-team" and "canconfirm". So, you should work now on the issues in Bugzilla. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Volunteer
Am 12/17/2016 05:58 PM, schrieb jakob.jawor...@t-online.de: my name is Jakob Jaworski, I am 32 years old and from germany. I am currently studying business information systems. My passion is testing, I am getting prepared to do the ISTQB Foundation Level Certification. As my theoretical knowledge on testing is good I now would like to gain some more practical knowledge. I have made first expirence in the field of testing in a real project and i really did enjoy the work. Therefore, it would be nice to contribute to this project in the field of QA. I have worked as a tutor in the fieldd of obejct oriented programming in Java at my university for more than 1 year. I also have created tutorials for my university for JavaFx, Debugging and Junit. In a project where i supported the testmanagment i created testcases, managed the testprocess and the integrationstest. Jakob, welcome to the project. The QA area is not the best documented one. So, for questions please ask here. Have fun. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Volunteer
Am 12/16/2016 01:40 AM, schrieb Lane Merrill: Strangely enough I am getting your emails addressed to the QA at openoffice but I am not the QA at openoffice. There must be some sort of glitch in the system. you get mails because you are subscribed to the mailing list. If you want to unsubscribe please see the text at the end of this mail. Marcus -- From: "Anuradha Patil" Sent: Tuesday, December 13, 2016 5:44 PM To: Subject: Volunteer Hi, I am unable to add myself to the volunteer list. Please help me do so. Thank you - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Adding into Bugzilla list
Am 11/12/2016 04:08 AM, schrieb Abhishek Mehendale: Please add me into BugZilla list. I will try my best to help the community. My username is: mehendaleabh...@gmail.com welcome to the Apache OpenOffice project. Thank you very much for your interst in helping us. I've added your user account to the groups "qa-team" and "canconfirm", so that you should be able to work on the issues. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Bugzilla Upgrade
Hi all, FYI The Apache Infra team has updated the Bugzilla installation. At the first view it seems nothing has been changed, so the Look & Feel is still the same. However, when looking closer you will see some new fields: - New field "Alias" A short, unique name assigned to an issue in order to assist with looking it up and referring to it in other places in Bugzilla. - New field "Personal Tags" Unlike Keywords which are global and visible by all users, Personal Tags are personal and can only be viewed and edited by their author. Editing them won't send any notification to other users. Use them to tag and keep track of issues. - New field "Ignore Issue Mail" [ ] Check when you never want to get emailed about this issue. - Comments With the button [Preview] you can view how the comment would look like if you save your updates. With the button [Comment] you can go on commenting. Have fun Marcus Am 11/05/2016 10:30 PM, schrieb Mark Thomas: As you've probably noticed, your Bugzilla instance was upgraded a few minutes ago to 5.0.3. I've run some basic tests and all looks OK but, as always, if you notice a problem please let infra know. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [QA] - Add to the "qa-team" group in Bugzilla
Am 10/28/2016 12:58 PM, schrieb Jakub Haraśny: Hi, I have subscribed to the QA mailing list. Please add me to: "qa-team" group in Bugzilla I have two accounts in bugzilla: 1. jakubhara...@gmail.com - this account I will be using in the future for QA purposes 2. jakub.hara...@testpartners.co.uk - this is account which I used previously and on which I received invitation/ information about AOO QA. This is my work email and I will be not using it anymore and I will not have access to it. If there is a chance to merge this accounts anyway then please, if not then please just ad first to the qa-team group in Bugzilla. we have still both user accounts in BZ. For your @gmail.com account I've added the "qa-team" group. HTH Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [PROPOSAL] General Availability of ApacheOpenOffice 4.1.2-patch1 Hotfixes
Am 08/23/2016 08:08 PM, schrieb Dennis E. Hamilton: [BCC PMC, FYI QA and L10N] There have been no comments concerning the placement of the current materials into general distribution. In addition, there is a set of Dutch (Nederland) language that also passes all tests and has been carefully proof-read. These have been added to the directory folder. (They are not reflected in the hotfix.html so far.) I would prefer to have an own webpage for all languages. Otherwise we will have a hugh webpage for a little patch which isn't looking smart IMHO. A set of German (Deutsch) language scripts has been prepared and had to be changed from Unicode (UTF8) to ISO 8859-1 (Western European) in order to run properly on Windows XP. The script window does not show extended characters used in German on an English Windows XP, but the scripts run correctly. They should appear correctly in Windows XP installs set for Western European languages. This part remains to be confirmed. See<https://bz.apache.org/ooo/show_bug.cgi?id=127082>. If the German version is not complete today, I propose going ahead with the general distribution of the English and Dutch ones and adding the German set later. German won't be ready in the next hours but hopefuĺly within this week. So, we should go online with the stuff we have. Marcus -Original Message- From: Dennis E. Hamilton [mailto:orc...@apache.org] Sent: Friday, August 19, 2016 15:02 To: d...@openoffice.apache.org Subject: [PROPOSAL] General Availability of ApacheOpenOffice 4.1.2- patch1 Hotfixes [BCC PMC, FYI QA] At this time, the preparation and dev@/qa@ confirmation of the AOO 4.1.2-patch1 Hotfixes has quieted. I propose that the current binaries be placed into general availability. I am initiating lazy consensus to end not before Tuesday, 2016-08- 23T22:00Z. MATERIALS TO BE AVAILABLE * The file hotfix.html at <https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/> will be made available at <https://archive.apache.org/dist/openoffice/4.1.2-patch1/> * The directory folder <https://dist.apache.org/repos/dist/dev/openoffice/4.1.2- patch1/binaries/> will be made available as a subdirectory of <https://archive.apache.org/dist/openoffice/4.1.2-patch1/>. ANNOUNCEMENT OF AVAILABILITY * The CVE-2016-1513 advisory, <http://www.openoffice.org/security/cves/CVE-2016-1513.html>, will be reissued to include availability of the hotfix and refer users to the hotfix.html page in the archive 4.1.2-patch1 location. * There will be an accompanying announcement on dev@, users@, and in the two bugzilla issues related to the defect that the hotfix applies to. WHAT TO REVIEW You can find everything to be made available by starting with the hotfix.html page at <https://dist.apache.org/repos/dist/dev/openoffice/4.1.2- patch1/hotfix.html>. IGNORE the Source column. The source release has already occurred, and those links will not be valid until deployment of hotfix.html to the archive location. The README files are the next materials to examine. There you can learn more about the hotfix for each of the four platforms: Windows, MacOSX, Linux32, and Linux64. Follow any of the procedures that you want to verify. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
Am 08/19/2016 01:09 AM, schrieb Dennis E. Hamilton: -Original Message- From: Keith N. McKenna [mailto:keith.mcke...@comcast.net] Sent: Thursday, August 18, 2016 14:46 To: qa@openoffice.apache.org; d...@openoffice.apache.org Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows [ ... ] [knmc] As we move forward to a general distribution here is an odt revision of the readme that can be used to generate an html, pdf, or text versions. All versions are attached but may not come through to the list. They can all be accessed from the following link. <https://1drv.ms/f/s!AMMYmStvrJNJgQQ> All feedback is both welcomed and encouraged. [orcmid] The .odt and the .txt file come through as attachments. Do you have specific recommendations about what should be done with these? I notice that there are problems with the .txt file layout not having hard line breaks. The name changes and dates in 0.2.0 are not reflected. The .odt also needs layout work. There's too much white space and I have not looked closely enough to figure out why. I know we differ on formatting and some document organization matters. I am not going to address them at this point. I am going to 1.0.0 now, essentially with the 0.2.0 except for the change of version number and removal of the limitation to testing use. I did the other repair you suggested. I think Marcus is ready on the other binaries, so something will happen tomorrow (Friday). I'm not certain what the final inch is just yet, but it looks like everything is ready enough. I haven't read the updates from Keith yet. But when they have no real news and are just formulation and layout updates, then I suggest to let us go live with text and binaries we have now. We can think about to update them after that with no hurry anymore. The announcement about the source patch was ~1 month ago. We shouldn't wait any longer with the binary patches. Sorry Keith. ;-) Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
Am 08/16/2016 05:26 AM, schrieb Dennis E. Hamilton: BETA 0.2.0 IS NOW AVAILABLE This is a cleanup version. It is hoped that this will be the last change before bumping the version to 1.0.0 and making general availability. One important change: The names of the files have been changed. The README is now named README-4.1.2-patch1-Windows.txt. The zip and the related .asc, .md5, .sha1, and .sha256 files all have the base name apache-openoffice-4.1.2-patch1-Win_x86.zip The two scripts also have simpler names: APPLY-4.1.2-patch1.bat REVERT-4.1.2-patch1.bat The files are still available at <https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/Windows> Now it is worth testing enough to know there is no regression and that APPLY and REVERT operate properly as before. I've downloaded the new ZIP and tested again: - Download new ZIP file OK - Unzipping OK - ASC signature OK - MD5 OK - SHA1 OK - SHA256OK - "tl.dll.new" ASC signature OK - "tl.dll.old" ASC signature OK The both .bat files differ from the past ones. I've not run the new ones again but looked closely to the diff output. There are no functional changes but only for file name and version. If I should run them again, just tell me. Otherwise I think also this ZIP is ready to do its work. Marcus -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Thursday, August 11, 2016 21:08 To: d...@openoffice.apache.org Cc: qa@openoffice.apache.org Subject: RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows BETA 0.1.0 WITH AUTOMATED SCRIPTS IS NOW AVAILABLE The scripts make life much easier, since users don't have to go hunting for anything and digging around in operating-system locations. You should be able to go through the procedure that uses the automated steps pretty easily. It is very important to know the difficulties that arise or whether there were none. The material is available at <http://dist.apache.org/repos/dist/dev/openoffice/4.1.2- patch1/binaries/Windows>. - Dennis -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Wednesday, August 10, 2016 18:01 To: d...@openoffice.apache.org Cc: qa@openoffice.apache.org Subject: RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows Beta version 0.1.0 is now nearing completion. It will include two scripts, one for applying the patch, the other for reverting the patch. The .zip will also have a copy of the original 4.1.2 tl.dll as well as the new one. These are used in the procedures to verify the files that are present in the OpenOffice configuration in order to apply the patch and also to remove it. Next steps: * Additional path testing of the two scripts and verification that operation on Windows XP and on Windows 10 work as expected. [orcmid] Done It is also much easier to work through the patch checks using the scripts. * Updating of the README to reflect the availability of the batch- file scripts as well as the manual procedure if ever needed. [orcmid] Done * Although the Zips already carry executable code (i.e., DLLs) there may be some Antivirus push-back where the policy is to not allow .zip files with scripts in them. The README will also have to address that possibility. [orcmid] I forgot that at the last minute. I will put that into the next version. Meanwhile, those who check these procedures should report any AV objections they ran into. - Dennis -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Monday, August 8, 2016 09:58 To: d...@openoffice.apache.org Cc: qa@openoffice.apache.org Subject: RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows Alpha version 0.0.1 of README-4.1.2-patch1-apply-Windows.txt has been introduced into the files (and the .zip) at <https://dist.apache.org/repos/dist/dev/openoffice/4.1.2- patch1/binaries/Windows>. This version reflects suggestions by Marcus Lange, Pedro Lino, and Keith McKenna. Suggestions that are not (yet) implemented will be discussed in replies to their messages and on the bugzilla issue at <https://bz.apache.org/ooo/show_bug.cgi?id=127065>. By its nature, this material is intended for users operating on Windows. In some cases, incompatible forms are used on the Subversion server where the above files are situated. Version 0.0.1 attempts to accommodate for this incompatibility. In continuing to verify the procedure, please indicate whether there are (now) difficulties using the text files, especially on Windows. Users of Linux systems may have difficulties with some utilities for which the Windows versions of the same tool (e.g., md5sum) do not produce Linux-acceptable line endings. It is useful to know
Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
Am 08/14/2016 07:10 PM, schrieb Dennis E. Hamilton: -Original Message- From: Marcus [mailto:marcus.m...@wtnet.de] Sent: Saturday, August 13, 2016 13:20 To: d...@openoffice.apache.org Cc: qa@openoffice.apache.org Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows [ ... ] PS: However, I've a point that could be improved. The name of the script files are very long. Same for the Readme. Inside the zip'ed file there is no need to repeat the complete patch name structure. IMHO they're better recognizable when it's just an "Apply.bat", "Revert.bat" and "Readme_Win.txt". [orcmid] I looked into the naming. These changes will help: 1. There is no longer any need for -apply in the names now that there is a single distribution that provides a script and provides manual instructions as an alternative. 2. There is no reason to mention -Windows in the name of a .bat file, since that is where those run these days. 3. I still want to be specific to 4.1.2-patch1 so that it is always clear what these are about, wherever the materials happen to be found on an user's PC. That should be evident without examining the .bat file or even knowing how to do that without causing it to be executed [;<). (It's a bit like the reasoning to have the README available to download directly so it can be read without downloading the full .zip.) I'll do all of this in a 0.2.0 beta that I'll build today, Sunday. There are some other suggestions that I will look into, after those are in the dev SVN, that may improve the text more. At this point, I am concerned about introducing regressions. I don't see this too negative. The good thing is: The regression cannot hide itself in an ASCII text. ;-) Marcus Thanks a lot for providing the script files. This will be a great help for the normal users. If you need more details or tests just tell me. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
Am 08/14/2016 10:17 AM, schrieb Marcus: Am 08/14/2016 01:07 AM, schrieb Dennis E. Hamilton: Thanks for the checking, Marcus. -Original Message- From: Marcus [mailto:marcus.m...@wtnet.de] Sent: Saturday, August 13, 2016 13:20 To: d...@openoffice.apache.org Cc: qa@openoffice.apache.org Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows Am 08/12/2016 06:07 AM, schrieb Dennis E. Hamilton: BETA 0.1.0 WITH AUTOMATED SCRIPTS IS NOW AVAILABLE The scripts make life much easier, since users don't have to go hunting for anything and digging around in operating-system locations. You should be able to go through the procedure that uses the automated steps pretty easily. It is very important to know the difficulties that arise or whether there were none. The material is available at <http://dist.apache.org/repos/dist/dev/openoffice/4.1.2- patch1/binaries/Windows>. great to have now a script-based installation. Here is my test procedure on Windows 10 Home: APPLY script: - When starting the script I get a "... Windows SmartScreen has prevented the start of a not recognized app. To run this App, Administrator permission is needed ..." message. Doing so, it started but showed a message [1] that Administrator permission is needed. I've verified that nothing was done or changed. - When starting with right-clicked "Run as Administrator" the script showed some useful information [1], renamed the old file and copied the new file. REVERT script: - When starting the script I get a "... Windows SmartScreen has prevented the start of a not recognized app. To run this App, Administrator permission is needed ..." message. Doing so, it started but showed a message [1] that Administrator permission is needed. I've verified that nothing was done or changed. - When starting with right-clicked "Run as Administrator" the script showed some useful information [1], deleted the new file and renamed the old file back to the old name. At the end both scripts are working successfully. [1] The command line window where the output information is shown uses a *very little* font size (looked like 4pt or similar) and is therefore nearyl unreadable. I had to increase the font size in the properties of the window (click on the icon in the top left corner). [orcmid] The font size is not under control of the script. I have no idea what has it be so small in your case. Changing it should be persistent now. yes, it must come from Windows. Actual it was a 10pt fonsize but with a resolution of ? x ? even this looks like much too small. I've pressed too fast the [Send] button. It's a 1920 x 1080 resolution. Marcus PS: However, I've a point that could be improved. The name of the script files are very long. Same for the Readme. Inside the zip'ed file there is no need to repeat the complete patch name structure. IMHO they're better recognizable when it's just an "Apply.bat", "Revert.bat" and "Readme_Win.txt". [orcmid] Well, yes, especially the Readme. At this late point, I'd like to get to 1.0.0 without risking any regression in the text. I don't like these things becoming mysteries if separated from the packages. I will give it serious consideration. You can put a descriptive text into the script as comment lines. So, then it's clear what it is and where it comes from. OK, if you don't want to change it for this patch then next time. ;-) Marcus Thanks a lot for providing the script files. This will be a great help for the normal users. If you need more details or tests just tell me. Marcus -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Wednesday, August 10, 2016 18:01 To: d...@openoffice.apache.org Cc: qa@openoffice.apache.org Subject: RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows Beta version 0.1.0 is now nearing completion. It will include two scripts, one for applying the patch, the other for reverting the patch. The .zip will also have a copy of the original 4.1.2 tl.dll as well as the new one. These are used in the procedures to verify the files that are present in the OpenOffice configuration in order to apply the patch and also to remove it. Next steps: * Additional path testing of the two scripts and verification that operation on Windows XP and on Windows 10 work as expected. [orcmid] Done It is also much easier to work through the patch checks using the scripts. * Updating of the README to reflect the availability of the batch- file scripts as well as the manual procedure if ever needed. [orcmid] Done * Although the Zips already carry executable code (i.e., DLLs) there may be some Antivirus push-back where the policy is to not allow .zip files with scripts in them. The README will also have to address that possibility. [orcmid] I forgot that at
Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
Am 08/14/2016 01:07 AM, schrieb Dennis E. Hamilton: Thanks for the checking, Marcus. -Original Message- From: Marcus [mailto:marcus.m...@wtnet.de] Sent: Saturday, August 13, 2016 13:20 To: d...@openoffice.apache.org Cc: qa@openoffice.apache.org Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows Am 08/12/2016 06:07 AM, schrieb Dennis E. Hamilton: BETA 0.1.0 WITH AUTOMATED SCRIPTS IS NOW AVAILABLE The scripts make life much easier, since users don't have to go hunting for anything and digging around in operating-system locations. You should be able to go through the procedure that uses the automated steps pretty easily. It is very important to know the difficulties that arise or whether there were none. The material is available at <http://dist.apache.org/repos/dist/dev/openoffice/4.1.2- patch1/binaries/Windows>. great to have now a script-based installation. Here is my test procedure on Windows 10 Home: APPLY script: - When starting the script I get a "... Windows SmartScreen has prevented the start of a not recognized app. To run this App, Administrator permission is needed ..." message. Doing so, it started but showed a message [1] that Administrator permission is needed. I've verified that nothing was done or changed. - When starting with right-clicked "Run as Administrator" the script showed some useful information [1], renamed the old file and copied the new file. REVERT script: - When starting the script I get a "... Windows SmartScreen has prevented the start of a not recognized app. To run this App, Administrator permission is needed ..." message. Doing so, it started but showed a message [1] that Administrator permission is needed. I've verified that nothing was done or changed. - When starting with right-clicked "Run as Administrator" the script showed some useful information [1], deleted the new file and renamed the old file back to the old name. At the end both scripts are working successfully. [1] The command line window where the output information is shown uses a *very little* font size (looked like 4pt or similar) and is therefore nearyl unreadable. I had to increase the font size in the properties of the window (click on the icon in the top left corner). [orcmid] The font size is not under control of the script. I have no idea what has it be so small in your case. Changing it should be persistent now. yes, it must come from Windows. Actual it was a 10pt fonsize but with a resolution of ? x ? even this looks like much too small. PS: However, I've a point that could be improved. The name of the script files are very long. Same for the Readme. Inside the zip'ed file there is no need to repeat the complete patch name structure. IMHO they're better recognizable when it's just an "Apply.bat", "Revert.bat" and "Readme_Win.txt". [orcmid] Well, yes, especially the Readme. At this late point, I'd like to get to 1.0.0 without risking any regression in the text. I don't like these things becoming mysteries if separated from the packages. I will give it serious consideration. You can put a descriptive text into the script as comment lines. So, then it's clear what it is and where it comes from. OK, if you don't want to change it for this patch then next time. ;-) Marcus Thanks a lot for providing the script files. This will be a great help for the normal users. If you need more details or tests just tell me. Marcus -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Wednesday, August 10, 2016 18:01 To: d...@openoffice.apache.org Cc: qa@openoffice.apache.org Subject: RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows Beta version 0.1.0 is now nearing completion. It will include two scripts, one for applying the patch, the other for reverting the patch. The .zip will also have a copy of the original 4.1.2 tl.dll as well as the new one. These are used in the procedures to verify the files that are present in the OpenOffice configuration in order to apply the patch and also to remove it. Next steps: * Additional path testing of the two scripts and verification that operation on Windows XP and on Windows 10 work as expected. [orcmid] Done It is also much easier to work through the patch checks using the scripts. * Updating of the README to reflect the availability of the batch- file scripts as well as the manual procedure if ever needed. [orcmid] Done * Although the Zips already carry executable code (i.e., DLLs) there may be some Antivirus push-back where the policy is to not allow .zip files with scripts in them. The README will also have to address that possibility. [orcmid] I forgot that at the last minute. I will put that into the next version. Meanwhile, those who check these procedures should
Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
Am 08/12/2016 06:07 AM, schrieb Dennis E. Hamilton: BETA 0.1.0 WITH AUTOMATED SCRIPTS IS NOW AVAILABLE The scripts make life much easier, since users don't have to go hunting for anything and digging around in operating-system locations. You should be able to go through the procedure that uses the automated steps pretty easily. It is very important to know the difficulties that arise or whether there were none. The material is available at <http://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/Windows>. great to have now a script-based installation. Here is my test procedure on Windows 10 Home: APPLY script: - When starting the script I get a "... Windows SmartScreen has prevented the start of a not recognized app. To run this App, Administrator permission is needed ..." message. Doing so, it started but showed a message [1] that Administrator permission is needed. I've verified that nothing was done or changed. - When starting with right-clicked "Run as Administrator" the script showed some useful information [1], renamed the old file and copied the new file. REVERT script: - When starting the script I get a "... Windows SmartScreen has prevented the start of a not recognized app. To run this App, Administrator permission is needed ..." message. Doing so, it started but showed a message [1] that Administrator permission is needed. I've verified that nothing was done or changed. - When starting with right-clicked "Run as Administrator" the script showed some useful information [1], deleted the new file and renamed the old file back to the old name. At the end both scripts are working successfully. [1] The command line window where the output information is shown uses a *very little* font size (looked like 4pt or similar) and is therefore nearyl unreadable. I had to increase the font size in the properties of the window (click on the icon in the top left corner). PS: However, I've a point that could be improved. The name of the script files are very long. Same for the Readme. Inside the zip'ed file there is no need to repeat the complete patch name structure. IMHO they're better recognizable when it's just an "Apply.bat", "Revert.bat" and "Readme_Win.txt". Thanks a lot for providing the script files. This will be a great help for the normal users. If you need more details or tests just tell me. Marcus -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Wednesday, August 10, 2016 18:01 To: d...@openoffice.apache.org Cc: qa@openoffice.apache.org Subject: RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows Beta version 0.1.0 is now nearing completion. It will include two scripts, one for applying the patch, the other for reverting the patch. The .zip will also have a copy of the original 4.1.2 tl.dll as well as the new one. These are used in the procedures to verify the files that are present in the OpenOffice configuration in order to apply the patch and also to remove it. Next steps: * Additional path testing of the two scripts and verification that operation on Windows XP and on Windows 10 work as expected. [orcmid] Done It is also much easier to work through the patch checks using the scripts. * Updating of the README to reflect the availability of the batch-file scripts as well as the manual procedure if ever needed. [orcmid] Done * Although the Zips already carry executable code (i.e., DLLs) there may be some Antivirus push-back where the policy is to not allow .zip files with scripts in them. The README will also have to address that possibility. [orcmid] I forgot that at the last minute. I will put that into the next version. Meanwhile, those who check these procedures should report any AV objections they ran into. - Dennis -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Monday, August 8, 2016 09:58 To: d...@openoffice.apache.org Cc: qa@openoffice.apache.org Subject: RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows Alpha version 0.0.1 of README-4.1.2-patch1-apply-Windows.txt has been introduced into the files (and the .zip) at <https://dist.apache.org/repos/dist/dev/openoffice/4.1.2- patch1/binaries/Windows>. This version reflects suggestions by Marcus Lange, Pedro Lino, and Keith McKenna. Suggestions that are not (yet) implemented will be discussed in replies to their messages and on the bugzilla issue at <https://bz.apache.org/ooo/show_bug.cgi?id=127065>. By its nature, this material is intended for users operating on Windows. In some cases, incompatible forms are used on the Subversion server where the above files are situated. Version 0.0.1 attempts to accommodate for this incompatibility. In continuing to verify the procedure, please indicate whether there
Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
Am 08/07/2016 07:30 PM, schrieb Dennis E. Hamilton: -Original Message- From: Marcus [mailto:marcus.m...@wtnet.de] Sent: Sunday, August 7, 2016 09:21 To: d...@openoffice.apache.org Cc: qa@openoffice.apache.org Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows Feedback for the .zip file: Do you have a reason in mind for the "apply" in the file name? I would delete this as I don't see a benefit and it would shorten the file name. [orcmid] I used the apply suffix to allow for there being a (semi-)automatic version that worked automatically later. I would then propose hotfix or something for that. This allowed for both to exist at some point. I'd rather not change that now since folks know to look for it by that name, it is used in the readme, etc. it's just a test version which can still be changed. So, I would shorten the name it and edit also the README. When extracting a ZIP file I cannot stand it when no subdirectory is included and the files are extracted where the current directory is at the moment. So, I've to search for the new files. [orcmid] The Extract ... tool for Windows automatically creates a folder to put everything into, although it will be in the same folder as the .zip. So having a folder in there simply adds an extra level. That is using the Windows extract. Ah, OK. I always use "Extract here". Other tools, such as WinZip also allow the user to choose a folder destination, although it might take more work, and knowledgeable users of Zip tools know how to tell what to do that works according to the README. Marcus Therefore please include a "files" dir (or similar name) into the ZIP file. [orcmid] The normal choice would be something like 4.1.2-patch1-apply :). Feedback for the README file. [orcmid] Thank you. I will go over all of the suggestions on the README that have come in so far, and provide an update today. Line 25: It should be improve into "please consult a knowledgable person (e.g., family member work colleauge, acquaintance) that is able to assist you". At least for me it sounds better. Line 41. Put all OPTIONAL things at the section end. Line 44/45: old: "... that are part of the system.installed." new: "... that are part of the installed system." Line 64/65: One "which" is double. Line 86-89: I don't know if this is necessary for this process. I think it would just foster help requests to the dev@ mailing list. Line 111: I would write ", the .zip file is available to use.". Line 114: One "or" is double. Line 131: No, there is no folder extracted. Please include one (see at the top of this mail). [orcmid] Did you not use the Windows "Extract ..." action on the context menu? Line 147: IMHO this was stated already. Please don't rename the new file in the ZIP file. Otherwise the user has to do an additional file rename which should not be done. [orcmid] That must be a misunderstanding. I don't propose anything like that. Line 153: The same for the ASC file. Line 183 and 186: Both parts can be described together to save 1 step. Line 208: This step should be avoided (see at the top of this mail). Line 222-231: As stated previously (line 86-89). Line 240: To give (again) the hint that OpenOffice should be closed before renaming the files would be nice to the user. I hope this feedback is helpful for you. [orcmid] Yes, thank you. I will look more closely when making the edits. Marcus Am 08/03/2016 05:31 AM, schrieb Dennis E. Hamilton: Testing of an Apache OpenOffice 4.1.2-patch1 procedure is requested. The files to be used in testing are at <https://dist.apache.org/repos/dist/dev/openoffice/4.1.2- patch1/binaries/Windows>. The files to be tested and reviewed are * README-4.1.2-patch1-apply-Windows.txt The description of the procedure for applying a corrected library file to installed copies of Apache OpenOffice 4.1.2 on Windows. Read this first before deciding to download the Zip file and attempting the procedure. * apache-openoffice-4.1.2-patch1-apply-Win_x86.zip The Zip archive containing the files to be used in the procedure. There is a copy of the README within the archive as well. * apache-openoffice-4.1.2-patch1-apply-Win_x86.zip.asc * apache-openoffice-4.1.2-patch1-apply-Win_x86.zip.md5 * apache-openoffice-4.1.2-patch1-apply-Win_x86.zip.sha256 Files that provide a digital signature, an MD5 hash, and an SHA256 hash that can be used to verify the integrity of the download and, in the case of the digital signature, the authenticity and accuracy of the download. REQUESTED TESTING * [OPTIONAL] If you are able to check any of the .asc, .md5, and .sha256 files against the .zip, report any difficulties that may have been encountered. * If
Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
Feedback for the .zip file: Do you have a reason in mind for the "apply" in the file name? I would delete this as I don't see a benefit and it would shorten the file name. When extracting a ZIP file I cannot stand it when no subdirectory is included and the files are extracted where the current directory is at the moment. So, I've to search for the new files. Therefore please include a "files" dir (or similar name) into the ZIP file. Feedback for the README file. Line 25: It should be improve into "please consult a knowledgable person (e.g., family member work colleauge, acquaintance) that is able to assist you". At least for me it sounds better. Line 41. Put all OPTIONAL things at the section end. Line 44/45: old: "... that are part of the system.installed." new: "... that are part of the installed system." Line 64/65: One "which" is double. Line 86-89: I don't know if this is necessary for this process. I think it would just foster help requests to the dev@ mailing list. Line 111: I would write ", the .zip file is available to use.". Line 114: One "or" is double. Line 131: No, there is no folder extracted. Please include one (see at the top of this mail). Line 147: IMHO this was stated already. Please don't rename the new file in the ZIP file. Otherwise the user has to do an additional file rename which should not be done. Line 153: The same for the ASC file. Line 183 and 186: Both parts can be described together to save 1 step. Line 208: This step should be avoided (see at the top of this mail). Line 222-231: As stated previously (line 86-89). Line 240: To give (again) the hint that OpenOffice should be closed before renaming the files would be nice to the user. I hope this feedback is helpful for you. Marcus Am 08/03/2016 05:31 AM, schrieb Dennis E. Hamilton: Testing of an Apache OpenOffice 4.1.2-patch1 procedure is requested. The files to be used in testing are at <https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/Windows>. The files to be tested and reviewed are * README-4.1.2-patch1-apply-Windows.txt The description of the procedure for applying a corrected library file to installed copies of Apache OpenOffice 4.1.2 on Windows. Read this first before deciding to download the Zip file and attempting the procedure. * apache-openoffice-4.1.2-patch1-apply-Win_x86.zip The Zip archive containing the files to be used in the procedure. There is a copy of the README within the archive as well. * apache-openoffice-4.1.2-patch1-apply-Win_x86.zip.asc * apache-openoffice-4.1.2-patch1-apply-Win_x86.zip.md5 * apache-openoffice-4.1.2-patch1-apply-Win_x86.zip.sha256 Files that provide a digital signature, an MD5 hash, and an SHA256 hash that can be used to verify the integrity of the download and, in the case of the digital signature, the authenticity and accuracy of the download. REQUESTED TESTING * [OPTIONAL] If you are able to check any of the .asc, .md5, and .sha256 files against the .zip, report any difficulties that may have been encountered. * If you performed the procedure, report * the version of Microsoft Windows and the type of account used (administrator or standard user). * report whether the procedure succeeded * if the procedure failed or met with difficulties, please summarize the problems and how you over- came any of them * [IMPORTANT] Identify any missing, incomplete or confusing information in the README. Describe what you see as important improvements before making general release of the procedure for use by non-expert users of Apache OpenOffice on Windows. The goal is to provide as much as we can to assist Windows users in applying this fix with confidence and success. The experience of more-knowledgable users who appreciate the difficulties of non-experts is important in achieving that. Thank you for any effort you invest and the feedback you provide. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
Am 08/03/2016 05:31 AM, schrieb Dennis E. Hamilton: Testing of an Apache OpenOffice 4.1.2-patch1 procedure is requested. The files to be used in testing are at <https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/Windows>. The files to be tested and reviewed are * README-4.1.2-patch1-apply-Windows.txt The description of the procedure for applying a corrected library file to installed copies of Apache OpenOffice 4.1.2 on Windows. Read this first before deciding to download the Zip file and attempting the procedure. wow, really? I think I need much more time for this than an average evening. ;-) I'll do the README steps on Sunday. * apache-openoffice-4.1.2-patch1-apply-Win_x86.zip The Zip archive containing the files to be used in the procedure. There is a copy of the README within the archive as well. - I've exchanged the DLL - Created a new text and presentation document with simple content. - Both were reopened successfully. Anything more to test? * apache-openoffice-4.1.2-patch1-apply-Win_x86.zip.asc I don't know if this is OK or still bad: gpg --verify apache-openoffice-4.1.2-patch1-apply-Win_x86.zip.asc apache-openoffice-4.1.2-patch1-apply-Win_x86.zip gpg: Signature made Tue 02 Aug 2016 06:24:08 AM CEST using RSA key ID D456628A gpg: Good signature from "keybase.io/orcmid (confirmed identifier) " gpg: aka "orcmid (Dennis E. Hamilton) " gpg: aka "orcmid Apache (code signing) " gpg: aka "Dennis E. Hamilton (orcmid) " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. * apache-openoffice-4.1.2-patch1-apply-Win_x86.zip.md5 Windows 10 Home (Version 1511): I've visually compared the MD5 hashes from the ZIP and MD5 file --> OK Linux: $ md5sum -c apache-openoffice-4.1.2-patch1.zip.md5 --> OK * apache-openoffice-4.1.2-patch1-apply-Win_x86.zip.sha256 Windows 10 Home (Version 1511): I've visually compared the SHA256 hashes from the ZIP and SHA256 file --> OK Linux: $ sha256sum -c apache-openoffice-4.1.2-patch1.zip.sha256 --> OK REQUESTED TESTING * [OPTIONAL] If you are able to check any of the .asc, .md5, and .sha256 files against the .zip, report any difficulties that may have been encountered. Please remove the new line at the end of the MD5 file. Otherwise it doesn't work on Linux: md5sum -c apache-openoffice-4.1.2-patch1-apply-Win_x86.zip.md5 : No such file or directory.1.2-patch1-apply-Win_x86.zip : FAILED open or read.2-patch1-apply-Win_x86.zip md5sum: WARNING: 1 of 1 listed file could not be read * If you performed the procedure, report * the version of Microsoft Windows and the type of account used (administrator or standard user). Windows 10 Home (Version 1511) Administrator * report whether the procedure succeeded Yes * if the procedure failed or met with difficulties, please summarize the problems and how you over- came any of them To do a quick check, I've used a shortcut: I've used the Total Commander (started as administrator, a normal user cannot modify anything in the OpenOffice directory) and exchanged the DLL. * [IMPORTANT] Identify any missing, incomplete or confusing information in the README. Describe what you see as important improvements before making general release of the procedure for use by non-expert users of Apache OpenOffice on Windows. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [QA] Request for Bugzilla "qa-team" group
Am 04/16/2016 02:14 AM, schrieb Buddy Matula: Hi, My name is Theodore Matula and I am a new QA volunteer. My Bugzilla login ID is buddymat...@gmail.com. I am requesting to be added to the Bugzilla "qa-team" group so that I may start assigning reports to myself and confirm new defect reports. Thank you. I've added you to the groups "qa-team" and "canconfirm". Welcome to the team. Have fun. :-) Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [DISCUSS] Cleanup needed for RESOLVED-FIXED issues
Am 04/07/2016 12:43 AM, schrieb Kay Schenk: [...] A warning -- unless you can see an SVN commit clearly stating that the fix has been ported to one of our existing releases, it may take a bit of investigation into the release branch area to determine this. release branch area-- http://svn.apache.org/viewvc/openoffice/branches/ Our new resolution of FIXED_WITHOUT_CODE should result in CLOSING without any further investigation. Thoughts on undertaking this cleanup? many issues are commented with "fixed in CMS xyz" but there are no real commits visible. Not every CWS was committed into Trunk before the project and software was transferred to Apache. So, do we have a list of outstanding CWS from 2011 that were not transferred to Apache? Thanks Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [DISCUSS] Cleanup needed for RESOLVED-FIXED issues
Am 04/08/2016 07:04 PM, schrieb Kay Schenk: On Thu, Apr 7, 2016 at 3:58 PM, Kay Schenk wrote: On Thu, Apr 7, 2016 at 9:59 AM, Marcus wrote: Am 04/07/2016 06:35 PM, schrieb Dennis E. Hamilton: My only concern is that this is a giant CTR and pretty much assures that the "R" will not happen. yes, but especially with old issues I don't see a big problem here. Maybe for single issues. But IMHO this is no argument to keep every issue open and inspect them in all details. Then it's better to reopen some of them. Ok, perhaps some misunderstanding here. What I'm asking for is assistance is finding the RESOLVED-FIXED issues that actually were incorporated in a release, and CLOSE them. Some of them even have comments that the issue was checked against a release, but they were not CLOSEd. I am NOT requesting that RESOLVED-FIXED issues that did not make it to a release be closed. This would be premature. Sorry for the misunderstanding. When it's "RESOLVED - FIXED", then I trust the status somehow and will only do some checks. But I don't put the resolution "FIXED" into doubt and do everything again that is listed in the issue. So be it. However, do not disable the issues mails for any reason. There is a difference between R not happening and R not being possible. That's right. The search I referenced in the first post has more than 1500 issues in the RESOLVED-FIXED category. Of these, some percentage should be CLOSEd. And yes, it's a bit of an annoyance to get the emails, but I think it's worth it to keep better records. Marcus A great big THANK YOU for the work done on this cleanup business so far. SUPER! please, no. ;-) Judging for these issues is easy without fixes for any OpenOffice code. I'll answer your other mail later. And try to close more issues in the next days. Marcus -Original Message- From: Marcus [mailto:marcus.m...@wtnet.de] Sent: Thursday, April 7, 2016 02:10 To: d...@openoffice.apache.org Cc: qa@openoffice.apache.org Subject: Re: [DISCUSS] Cleanup needed for RESOLVED-FIXED issues [ ... ] I've closed all listed issues regarding our infrastructure (Website, Bugzilla, etc.). As you can see every single change results in a mail and will fill everybody's inbox - when you are subscribed to the issues@ mailing list. There will be the possibility to disable mails when performing special actions (e.g., bulk issue changes) but not before release 6.0 [1]. At the moment we are at 5.0.2. So, it will take some more time. ;-( For the time being we have only the way do disable completely sending mails when we work on the issue. But this means that *absolutely no mails will be sent* regardless what was done (new issue, change, comments, closing, etc.). [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1062718 Sorry for the spam. ;-) Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [DISCUSS] Cleanup needed for RESOLVED-FIXED issues
Am 04/07/2016 12:43 AM, schrieb Kay Schenk: I think typically the process for RESOLVED-FIXED (those issues that were fixed by some kind of code change to /trunk) issues is to: * commit the change to a release build * once the release build is out for testing, check that the bug is fixed, and use RESOLVED-VERFIED, to verify the fix, then * CLOSE the issue Recently, when I was looking at some issues that we'd targeted for 4.1.2, I came upon a number that had been RESOLVED-FIXED, but some had been committed to a release and some had not. For those that had, I skipped the RESOLVED-VERIFIED step and just closed them. Currently, I feel we could use some additional help with a) closing out old issues that have been ported to a release, and b) resetting the Target Release information for those issues that have been fixed but have not been "released". The following query only looks at RESOLVED-FIXED issues since 2011-01-01 https://bz.apache.org/ooo/buglist.cgi?bug_status=RESOLVED&chfield=resolution&chfieldfrom=2011-01-01&chfieldto=Now&chfieldvalue=Fixed&limit=0&order=priority%2Cbug_severity&query_format=advanced&resolution=FIXED&resolution=FIXED_WITHOUT_CODE A warning -- unless you can see an SVN commit clearly stating that the fix has been ported to one of our existing releases, it may take a bit of investigation into the release branch area to determine this. release branch area-- http://svn.apache.org/viewvc/openoffice/branches/ Our new resolution of FIXED_WITHOUT_CODE should result in CLOSING without any further investigation. Thoughts on undertaking this cleanup? I've closed all listed issues regarding our infrastructure (Website, Bugzilla, etc.). As you can see every single change results in a mail and will fill everybody's inbox - when you are subscribed to the issues@ mailing list. There will be the possibility to disable mails when performing special actions (e.g., bulk issue changes) but not before release 6.0 [1]. At the moment we are at 5.0.2. So, it will take some more time. ;-( For the time being we have only the way do disable completely sending mails when we work on the issue. But this means that *absolutely no mails will be sent* regardless what was done (new issue, change, comments, closing, etc.). [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1062718 Sorry for the spam. ;-) Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Issues need 4.2.0 as Target Milestone
Am 03/31/2016 08:26 PM, schrieb Marcus: Am 03/31/2016 07:19 PM, schrieb Andrea Pescetti: Marcus wrote: Target milestones depend on the product in BZ. There is no 4.2.0 target right now (except for "gsl"). I marked (in the past) several issues as target 4.2.0, not only in gsl. Now I see that in https://bz.apache.org/ooo/query.cgi the Target Milestone box contains both "4.2.0" and "AOO 4.2.0". The latter should not be there, whatever product one chooses. the "AOO ..." targerts are coming from disabled products. Issues cannot be created within these products. However with a query they are of course reachable. It seems I need some more time to fix this also. Then we should be so consequent and do the same for the version values. Done: target milestones Todo: versions But now there is a new flag "4.2.0_release_blocker" which can maybe help in the meantime. Thanks! Of course, for a 4.2.0 release, the meaning is different than in the past. It will mean "something that is not fixed yet and that it must fixed by 4.2.0" (and it will make sense to use it when closer to the RC). Since we have no branch for 4.2.0 yet, and we won't until we are close to the release, it will not mean "something that is fixed in trunk and should ported to the release branch" for the moment. So, you mean it would be better to disable the flag for the time being? Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Am 03/31/2016 07:40 PM, schrieb Andrea Pescetti: Marcus wrote: OK, as there were no further comments and no real disagree I'll create a new RESOLVED - NOCODEFIX resolution status. This status should be set when an issue was solved with no change in the source code (e.g., user requests or how-to questions). What's the maximum length? Maybe FIXED_WITHOUT_CODE is even more intuitive (but OK for me with the other option too!). I've created both and got no problem or error message. OK, you won ;- ) : New status is FIXED_WITHOUT_CODE. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Issues need 4.2.0 as Target Milestone
Am 03/31/2016 07:19 PM, schrieb Andrea Pescetti: Marcus wrote: Target milestones depend on the product in BZ. There is no 4.2.0 target right now (except for "gsl"). I marked (in the past) several issues as target 4.2.0, not only in gsl. Now I see that in https://bz.apache.org/ooo/query.cgi the Target Milestone box contains both "4.2.0" and "AOO 4.2.0". The latter should not be there, whatever product one chooses. the "AOO ..." targerts are coming from disabled products. Issues cannot be created within these products. However with a query they are of course reachable. It seems I need some more time to fix this also. Then we should be so consequent and do the same for the version values. But now there is a new flag "4.2.0_release_blocker" which can maybe help in the meantime. Thanks! Of course, for a 4.2.0 release, the meaning is different than in the past. It will mean "something that is not fixed yet and that it must fixed by 4.2.0" (and it will make sense to use it when closer to the RC). Since we have no branch for 4.2.0 yet, and we won't until we are close to the release, it will not mean "something that is fixed in trunk and should ported to the release branch" for the moment. So, you mean it would be better to disable the flag for the time being? Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
[Top-Posting] OK, as there were no further comments and no real disagree I'll create a new RESOLVED - NOCODEFIX resolution status. This status should be set when an issue was solved with no change in the source code (e.g., user requests or how-to questions). For every fix that touches the source code please use as always the RESOLVED - FIXED resolution status. Marcus Am 03/26/2016 10:58 AM, schrieb Marcus: Am 03/26/2016 10:50 AM, schrieb Andrea Pescetti: Marcus wrote: Am 03/26/2016 12:13 AM, schrieb Andrea Pescetti: If the aim is to create less confusion, all proposals I've seen have the result of bringing more confusion! So: I don't see why this brings more confusion. It's the opposite, one status for "resolved with a code fix" and the other for "resolved somehow else". It brings more confusion since it would need to be explained explicitly (because DONE or MANAGED would apply, looking purely at their meaning, to a code fix too, and it's only a convention that we use them for "no-code" fixes only). maybe, but the whole BZ can be confusing - especially for normal users. ;-) > And if we have more intuitive options I feel this would be better. Do you have any idea in mind? It doesn't have to be "NOCODE", but it should be something that means "nothing to do with code", and DONE does not really convey the right meaning here. Then NOCODEFIX sounds more concrete. Yes, NOCODEFIX sounds good too. Again, so long as it is a word that a developer cannot be mistaken into choosing instead of FIXED, it will be OK for me. What we want to avoid is that a developer accidentally uses DONE for a code fix and the issue is suddenly not listed in QA and similar. I got the idea to rename FIXED into FIXEDINCODE. Unfortunatelly, it's a default and therefore a non-changeable name. :-( - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Issues need 4.2.0 as Target Milestone
Am 03/31/2016 01:54 AM, schrieb Kay Schenk: Well a few days ago, I changed a bunch of RESOLVED-FIXED to 4.2.0 milestone so I just assumed it was available for all issues: https://bz.apache.org/ooo/buglist.cgi?query_format=advanced&resolution=---&target_milestone=4.2.0 So confusing to say the least. the targets were a bit messed up. I've cleaned them up and added to all enabled products a "4.2.0" target. If something is missing just give me a hint. Thanks Marcus On 03/30/2016 04:04 PM, Marcus wrote: Target milestones depend on the product in BZ. There is no 4.2.0 target right now (except for "gsl"). Targets have to be created manually for every product. I'll do this tomorrow as it's already late here. But now there is a new flag "4.2.0_release_blocker" which can maybe help in the meantime. BTW: You were just a few seconds faster with your mail than me. ;-) Marcus Am 03/31/2016 12:59 AM, schrieb Kay Schenk: I'm not sure how this happened but it seems not all issues can access 4.2.0 as Target Milestone. I would think all issues could access the same Target Milestone menu. I hope this can be corrected. Thanks. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Issues need 4.2.0 as Target Milestone
Target milestones depend on the product in BZ. There is no 4.2.0 target right now (except for "gsl"). Targets have to be created manually for every product. I'll do this tomorrow as it's already late here. But now there is a new flag "4.2.0_release_blocker" which can maybe help in the meantime. BTW: You were just a few seconds faster with your mail than me. ;-) Marcus Am 03/31/2016 12:59 AM, schrieb Kay Schenk: I'm not sure how this happened but it seems not all issues can access 4.2.0 as Target Milestone. I would think all issues could access the same Target Milestone menu. I hope this can be corrected. Thanks. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Am 03/22/2016 04:48 PM, schrieb Dennis E. Hamilton: Many interesting ideas, ... -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Tuesday, March 22, 2016 03:35 To: d...@openoffice.apache.org Subject: Re: Can we add the value "N/A" to the Target Milestone field On 03/22/2016 05:02 AM, Marcus wrote: Am 03/22/2016 10:00 AM, schrieb Marcus: [ ,,, ] [ ... ] what about RESOLVED - MANAGED? This word is maybe better known in the world. This term shows that the issue has some work in it and was tackled. With a closing comment you can see where and why it was successful managed (resolved). from Jira I also know that RESOLVED - DONE is a common way to say that an issue was successfully resolved. Marcus Having a RESOLVED - DONE would be especially good for tasks also. [orcmid] MANAGED is interesting because of its flexibility. How it was managed should be accounted for in the commentary. ACK DONE does seem to apply to Tasks and Enhancement requests. Right, and user requests are very often nothing else (e.g., "my document is broken, how to repair it?"). DECLINED also seems to apply to both Tasks and Enhancements. It is also a counterpart to ACCEPTED in those cases. Yes, it doesn't indicate that there is a solution/workaround available. @all: It seems we could have a consensus in creating a new MANAGED or DONE status to set when issues are no real code problems, but more user-oriented. Finally, they were solved for the user's satisfaction (e.g., provided how-to's or repaired documents, etc.). However, no fix in the source code has been done. At qa@ Pedro Lino made some useful observations about how terms impact reporters and observers of the Bugzilla activity. In respect to that, I have been using WONTFIX as a way to indicate that we have no capacity to do anything about an issue, especially a longstanding one. This is primarily a way of discouraging non-project commenters arguing among themselves and to also indicate that the issue is understood, recognized, and continued lobbying is not useful. I think DECLINED may be useful in some of those cases, but WONTFIX is more truthful when the project doesn't have a way to do anything. NOTFIXING is closer to the reality. (CANTFIX would also indicate that the problem is not with the issue, but with project capability at this time.) The door is not closed completely, but it is not clear when the door will ever be opened. I agree that we do need a diagram and a description of the general application of Bugzilla categories and resolution cases. We might also need to revisit how the search defaults work with respect to the various categories. This seems like a good Wiki [update] effort. We also don't want to split things into so many categories that application and understanding becomes more difficult. After we have an agreement I can take over this task to grep the data in Wiki to consolidate and update them with the new information. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Am 03/22/2016 11:56 AM, schrieb Pedro Lino: It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED - NOTOURBUG is not much better than NOTANISSUE. RESOLVED - HANDLED might be closer, with the comment that achieves this explains how it is handled. (I.e., documentation, workaround, whatever.) I'm not in love with that term and don't know how it works for non-native English-language participants. I like it as it is more general. However, what about RESOLVED - MANAGED? This word is maybe better known in the world. This term shows that the issue has some work in it and was tackled. With a closing comment you can see where and why it was successful managed (resolved). from Jira I also know that RESOLVED - DONE is a common way to say that an issue was successfully resolved. NOT_AN_ISSUE seems a bad option. The problem which is affecting someone is dismissed. In my opinion it is as as offensive as WORKSFORME (used in LibreOffice) and WONT_FIX (used in both projects) +1 and additionally it doesn't show that the issue was solved. HANDLED, MANAGED only applies if there are workarounds (which is not always the case). No, I see this different. For me the wording is more general. So, it's not that important if there is a real solution or workaround or whatever for the iassue. NOTOURBUG means that the Devs looked at it and although they recognize it's a problem, there is nothing they can do because the problem is somewhere else. I agree it's a but short and rough but it's difficult to be nice and meaningful with a single word (or glued words). This can be further explained in the Comments when changing status if the developer is in such a mood... NOTABUG could be used instead of WONT_FIX (when it's reported as a bug but AOO decides it is working as expected) and DECLINED when it's a suggestion/enhancement (and AOO decides it is not interesting/productive) Additionally with NOTOURBUG and NOTABUG you cannot see that the issue has a workable and accepted solution. But this is a key point of this whole discussion. OK, it seems you also like the idea to have another resolution status - it just depends on what the name is, right? ;-) Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Am 03/22/2016 10:00 AM, schrieb Marcus: Am 03/22/2016 03:37 AM, schrieb Dennis E. Hamilton: -Original Message- From: Pedro Lino [mailto:pedl...@gmail.com] Sent: Monday, March 21, 2016 16:53 To: qa@openoffice.apache.org Subject: Re: Can we add the value "N/A" to the Target Milestone field It's not about to draw the line between issues that are resolved and verified solutions. It's about to differentiate issues that are in the real application and therefore need to be fixed in the source code. Here we use (or better should use) RESOLVED - FIXED. But what about issues that are also reporting a problem but the solution (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit, RESOLVED - NOT_AN_ISSUE also not. Why not use the same nomenclature as the "sibling project"? RESOLVED - NOTOURBUG [orcmid] It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED - NOTOURBUG is not much better than NOTANISSUE. RESOLVED - HANDLED might be closer, with the comment that achieves this explains how it is handled. (I.e., documentation, workaround, whatever.) I'm not in love with that term and don't know how it works for non-native English-language participants. I like it as it is more general. However, what about RESOLVED - MANAGED? This word is maybe better known in the world. This term shows that the issue has some work in it and was tackled. With a closing comment you can see where and why it was successful managed (resolved). from Jira I also know that RESOLVED - DONE is a common way to say that an issue was successfully resolved. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Am 03/22/2016 03:37 AM, schrieb Dennis E. Hamilton: -Original Message- From: Pedro Lino [mailto:pedl...@gmail.com] Sent: Monday, March 21, 2016 16:53 To: qa@openoffice.apache.org Subject: Re: Can we add the value "N/A" to the Target Milestone field It's not about to draw the line between issues that are resolved and verified solutions. It's about to differentiate issues that are in the real application and therefore need to be fixed in the source code. Here we use (or better should use) RESOLVED - FIXED. But what about issues that are also reporting a problem but the solution (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit, RESOLVED - NOT_AN_ISSUE also not. Why not use the same nomenclature as the "sibling project"? RESOLVED - NOTOURBUG [orcmid] It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED - NOTOURBUG is not much better than NOTANISSUE. RESOLVED - HANDLED might be closer, with the comment that achieves this explains how it is handled. (I.e., documentation, workaround, whatever.) I'm not in love with that term and don't know how it works for non-native English-language participants. I like it as it is more general. However, what about RESOLVED - MANAGED? This word is maybe better known in the world. This term shows that the issue has some work in it and was tackled. With a closing comment you can see where and why it was successful managed (resolved). I believe Apache QA needs a flowchart such as https://wiki.documentfoundation.org/images/c/c4/Unconfirmed_Bugs_Status_ Flowchart_Version_0.1.pdf https://wiki.documentfoundation.org/images/c/cb/Unconfirmed_Bugs_Status_Flowchart.odg [orcmid] Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Am 03/22/2016 12:52 AM, schrieb Pedro Lino: It's not about to draw the line between issues that are resolved and verified solutions. It's about to differentiate issues that are in the real application and therefore need to be fixed in the source code. Here we use (or better should use) RESOLVED - FIXED. But what about issues that are also reporting a problem but the solution (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit, RESOLVED - NOT_AN_ISSUE also not. Why not use the same nomenclature as the "sibling project"? RESOLVED - NOTOURBUG in general it's OK to look for other projects how they handle such problems. But NOTOURBUG sounds really ignorant and a bit offensive - at east in my ears. When I think about the users that reporting such issues and mostly they think it's important because they cannot go on with their work, then they deserve a more meaningful status name. Dennis has made a good suggestion where I'll go on with answering. I believe Apache QA needs a flowchart such as https://wiki.documentfoundation.org/images/c/c4/Unconfirmed_Bugs_Status_Flowchart_Version_0.1.pdf https://wiki.documentfoundation.org/images/c/cb/Unconfirmed_Bugs_Status_Flowchart.odg I'm pretty sure we have a similar flow chart somewhere in the depths of our Wiki. But yes, in general this would help to understand how the issue statuses are working together. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Am 03/22/2016 12:30 AM, schrieb Pedro Lino: On Mon, Mar 21, 2016 at 10:32 PM, Marcus wrote: Am 03/21/2016 10:36 PM, schrieb Kay Schenk: [top posting] Thanks for all the help with this and for the new NONE for target release. Hopefully, it will be used sparingly assuming we us e RESOLVED-FIXED as only for issues in which an actual commit is used. Issue 126828 has now been changed to UNCONFIRMED. How to differentiate UNCONFIRMED from RESOLVED--NOT AN ISSUE will be a challenge. Hopefully, this can be clarified to our QA helpers I repeat my suggestion for another resolution status as it maybe got lost in people's inboxes. My suggestion is to create a RESOLVED - RESOLVED status. Maybe still to close to RESOLVED - FIXED, but then let's see if there are better wordings. There is already a final status after RESOLVED - FIXED. It's VERIFIED - FIXED. It is set after a QA member verifies that the fix actually solved the problem and that it does not occur in the RC. Hope this helps. no, that's not what I meant. ;-) It's not about to draw the line between issues that are resolved and verified solutions. It's about to differentiate issues that are in the real application and therefore need to be fixed in the source code. Here we use (or better should use) RESOLVED - FIXED. But what about issues that are also reporting a problem but the solution (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit, RESOLVED - NOT_AN_ISSUE also not. Therefore I suggested a new status RESOLVED - RESOLVED. I hope this explains it better. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Am 03/21/2016 10:36 PM, schrieb Kay Schenk: [top posting] Thanks for all the help with this and for the new NONE for target release. Hopefully, it will be used sparingly assuming we us e RESOLVED-FIXED as only for issues in which an actual commit is used. Issue 126828 has now been changed to UNCONFIRMED. How to differentiate UNCONFIRMED from RESOLVED--NOT AN ISSUE will be a challenge. Hopefully, this can be clarified to our QA helpers I repeat my suggestion for another resolution status as it maybe got lost in people's inboxes. My suggestion is to create a RESOLVED - RESOLVED status. Maybe still to close to RESOLVED - FIXED, but then let's see if there are better wordings. Instead of setting to a status that doesn't make sense or to differentiate together with another field (like the target), why not setting an user issue that could be resolved to a status that actually show this. Marcus And, dang, one my examples was NOT a correct illustration of the problem. Too many BZ windows open yesterday I guess. Ok, back to my investigations. On 03/21/2016 12:05 PM, Dennis E. Hamilton wrote: -Original Message- From: Patricia Shanahan [mailto:p...@acm.org] Sent: Monday, March 21, 2016 09:10 To: d...@openoffice.apache.org Subject: Re: Can we add the value "N/A" to the Target Milestone field On 3/21/2016 8:59 AM, Kay Schenk wrote: On Sun, Mar 20, 2016 at 3:46 PM, Dennis E. Hamilton wrote: I want to clarify this. I think the problem might be that "Resolved - Fixed" is being used incorrectly. As far as I know, there are many cases where this resolution is used where one of "Resolved - Not an Issue" (though not too often), "Resolved - Irreproducible", "Resolved - Won't Fix", or "Resolved - Obsolete" should be used. Is that what you are seeing, Kay? Well maybe so. In the past, I have used RESOLVED-FIXED to determine what's been committed to our source, thus leading to a Target Release. Yesterday, I started going through RESOLVED-FIXED items to be sure some of these fixed issued did have a Target Release. Some of these RESOLVED- FIXED issues seem to be either user support issues/questions that do not entail source code corrections at all, or similar type situations. In one of the cases I sited above, I think the issue originator marked it with RESOLVED-FIXED, and really i don't know if this was the right thing to do or not. [orcmid] My impression is that original reporters rarely do this and might not even have the necessary karma. As you can see in one of the two you linked to, I was the guilty culprit [;<). So, we can use the new NONE (thank you Marcus!) as the Target Release, or do something else to ignore these types of issues for verification in a build. The problem is stemming from the use of BZ as both a code centric problem reporting mechanism and a user support tool. I don't think it should be marked RESOLVED-FIXED unless it was actually fixed, and therefore has a release in which the fix first appears. To me, RESOLVED-FIXED with a target release of NONE is self-contradictory. What is the objection to changing the resolution to reflect reality? For example, if it was a user support issue that does not entail a source code correction, shouldn't it be marked RESOLVED - NOT_AN_ISSUE rather than RESOLVED - FIXED with a target date of NONE? [orcmid] I agree that RESOLVED - FIXED might be inappropriate in many cases. However, RESOLVED - NOT AN ISSUE is often too heavy-handed. It can clearly be an issue to users, especially when it is an identifiable usability matter although not a code bug, but still there may be some clear product-behavior deficiency. And the issue may be recognized as such by the project, too. The problem is "Issue for Whom," when it is about a deficiency in the product but not a bug in the conventional sense. Since we our software is user-facing, it would be good to own that such issues are issues for us as providers of something valuable to users. BZ is our basic mechanism for existence and attention to such cases. I also recall seeing "NOT AN ISSUE" used when IRREPRODUCIBLE might be a better matter (i.e., when the reporter fails to provide needed details to know specifically what the matter is). Also, sometimes the "fix" is elsewhere (i.e., documentation, workarounds on a wiki, whatever). I suppose that means CONFIRMED but not acted on until cleared up somehow, or a WONT-FIX that indicates the workaround is all that is coming. I think it comes down to specific cases. The ability to have a RESOLVED-FIXED with a "None" release target is useful, and we now have it available. We just need to use it appropriately. It just means that the fix is other than in a code release. We also need to make clear what the gener
Re: Can we add the value "N/A" to the Target Milestone field
Am 03/20/2016 09:08 PM, schrieb Kay Schenk: We seem to have a number of issues in BZ that are now listed as Resolved/Fixed but don't seem to pertain to an actual upcoming release. Examples: https://bz.apache.org/ooo/show_bug.cgi?id=126652 https://bz.apache.org/ooo/show_bug.cgi?id=126828 Can we add something like "N/A" or the like to our Target Milestone field rather than the default "--" so we know these should never be considered for a release? sounds reasonable. I've added an "None" to the list of available milestones for many products (the application modules and related things). Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Should i change the status of a bug if i really think it is a bug
Am 11/20/2015 05:45 PM, schrieb Dolores Zurdo Consuegra: [...] They say that they could replicate the bug, but it is still like unconfirmed. maybe none of them have thought of changing the status or they simply have not the permissions. So my question is: Should the status of this bug be as confirmed or I'm changing the bug's status too fast? No, I think is this case it's OK to set the status to CONFIRMED. Latest when you test this and can see the issue also, then you should change the status. The 3 people have tested this with 4.1.1 and all comments are quiet recent - at least not years old. I'm asking this because i don't want to start to declarer bug too fast, in case i'm doing it wrong. Don't be affraid to make mistakes. Sooner or later this may happen. In the best case someone (maybe the issue reporter himself) will point you to that and then you can revert your action - or write another comment with correcting your last comment. > If it is so, please tell me, so i could review and change all the things that i have done so far. :-) That's OK. In general, look and test carefully and act as best as you can. :-) I hope this was helpful. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Join Bugzilla qa-team
Am 11/11/2015 05:31 AM, schrieb Karin Reid: Please can you add me to the 'qa-team' in Bugzilla. My Bugzilla id is : karinr...@yahoo.com welcome to the Apache OpenOffice project. I've changed the permissions for your Bugzilla account. You got the "canconfirm" and "qa-team" permission. This enables you to confirm issues and to set the right status. Have fun. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [BUGZILLA] The OS field is not sorted and could be therefore improved
As there was no objection or different opinions the changes were made and are now online. Marcus Am 11/07/2015 08:40 PM, schrieb Marcus: When creating a new issue (or for an existing one, if you want to choose a better one), then IMHO the users expect a different sorting. Therefore I want to improve the list to get the most used systems at top like the following: All Windows, all Windows XP Windows Vista Windows 7 Windows Server 2008 Windows Server 2012 Windows 8, 8.1 Windows 10 Mac OS X, all Mac OS X, 10.7 Mac OS X, 10.8 Mac OS X, 10.9 Mac OS X, 10.10 Mac OS X, 10.11 Linux, all Linux 32-bit Linux 64-bit Unix, all Solaris FreeBSD OS/2 Other OS - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [QA]
Am 11/10/2015 08:08 PM, schrieb Elena Tsepota: Please add me to the "qa-team" group in Bugzilla. My Bugzilla ID - tspt...@gmail.com I'm sorry but I cannot find a user account with this mail address. Also not with your first and last name. Can you please check about the spelling you have used to create the account? Thanks Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [QA]
Am 11/10/2015 11:41 AM, schrieb Dolores Zurdo Consuegra: Could you please add me to the "qa-team" group in Bugzilla. My login is: dolores.zurdo.consue...@gmail.com welcome to the Apache OpenOffice project. I've changed the permissions for your Bugzilla account. You got the "canconfirm" and "qa-team" permission. This enables you to confirm issues and to set the right status. Have fun. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [QA]
Am 11/09/2015 01:25 AM, schrieb Urmi Shah: Please add me to the "qa-team" group in Bugzilla. My Bugzilla ID - shahur...@outlook.com welcome to the Apache OpenOffice project. I've changed the permissions for your Bugzilla account. You got the "canconfirm" and "qa-team" permission. This enables you to confirm issues and to set the right status. Have fun. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Introduction for subscription
Am 11/08/2015 04:57 PM, schrieb Eugene Sokol: My name is Eugene, and I live in Ukraine. I`m a qualified translator/proofreader, with English, Ukrainian and Russian as source languages. I have about two years` experience as a freelance tester, and to gain some more knowledge as a QA specialist, I would like to participate in the AOO initiative. I have created a Bugzilla account, here is my login: goracio.tes...@mailinator.com . Please feel free to contact me, I am ready to provide some experienced assistance. welcome to the Apache OpenOffice project. I've changed the permissions for your Bugzilla account. You got the "canconfirm" and "qa-team" permission. This enables you to confirm issues and to set the right status. Have fun. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [BUGZILLA] The OS field is not sorted and could be therefore improved
Am 11/07/2015 08:48 PM, schrieb Dennis E. Hamilton: +1 I suggest that a lazy consensus be started on dev@ and, absent any objection, go ahead. done, you were a bit fast with your mail. ;-) Marcus (You could probably just do it. An account on dev@ is appropriate though.) -Original Message- From: Marcus [mailto:marcus.m...@wtnet.de] Sent: Saturday, November 7, 2015 11:40 To: qa@ Subject: [BUGZILLA] The OS field is not sorted and could be therefore improved When creating a new issue (or for an existing one, if you want to choose a better one), then IMHO the users expect a different sorting. Therefore I want to improve the list to get the most used systems at top like the following: All Windows, all Windows XP Windows Vista Windows 7 Windows Server 2008 Windows Server 2012 Windows 8, 8.1 Windows 10 Mac OS X, all Mac OS X, 10.7 Mac OS X, 10.8 Mac OS X, 10.9 Mac OS X, 10.10 Mac OS X, 10.11 Linux, all Linux 32-bit Linux 64-bit Unix, all Solaris FreeBSD OS/2 Other OS - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
[BUGZILLA] The OS field is not sorted and could be therefore improved
When creating a new issue (or for an existing one, if you want to choose a better one), then IMHO the users expect a different sorting. Therefore I want to improve the list to get the most used systems at top like the following: All Windows, all Windows XP Windows Vista Windows 7 Windows Server 2008 Windows Server 2012 Windows 8, 8.1 Windows 10 Mac OS X, all Mac OS X, 10.7 Mac OS X, 10.8 Mac OS X, 10.9 Mac OS X, 10.10 Mac OS X, 10.11 Linux, all Linux 32-bit Linux 64-bit Unix, all Solaris FreeBSD OS/2 Other OS - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: QA bug reports
Am 11/06/2015 11:07 PM, schrieb Andrea Pescetti: On 06/11/2015 David Haigh wrote: Do you have a small batch of reports to be assigned to me? Welcome to the QA list! Someone, probably Marcus, will soon give the right privileges to you and the other volunteers who joined today. I've changed the permissions for the 3 people who joined the last days and that I've found in Bugzilla. You got the "canconfirm" and "qa-team" permission to confirm issues and to set the right status. Have fun. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: We need 4.1.2 added to the version menu...
Am 10/29/2015 10:27 PM, schrieb Marcus: Am 10/29/2015 10:12 PM, schrieb Kay Schenk: Hello,BZ admins. It's time to add 4.1.2 to the Version menu list. I thought about this already today. Thanks for your hint. I'll start this now. Unfortunately, this has to be done product by product. So, this take some time. ah, it makes sense to add the new version only to products that are open to receive new issues. And these are only a few. So, it went faster then thought first. But the "Last Confirmation" field has already a 4.1.2 value. I've also disabled "4.1.2-dev" and "4.1.2" for the "Milestone" field. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: We need 4.1.2 added to the version menu...
Am 10/29/2015 10:12 PM, schrieb Kay Schenk: Hello,BZ admins. It's time to add 4.1.2 to the Version menu list. I thought about this already today. Thanks for your hint. I'll start this now. Unfortunately, this has to be done product by product. So, this take some time. But the "Last Confirmation" field has already a 4.1.2 value. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: karma needed on a query
Am 10/16/2015 12:51 AM, schrieb Kay Schenk: On 10/15/2015 02:37 PM, Marcus wrote: Am 10/15/2015 09:20 PM, schrieb Kay Schenk: The following query is being referenced in the release notes for 4.1.2 for "fixed issues"-- https://bz.apache.org/ooo/buglist.cgi?cmdtype=dorem&list_id=170710&namedcmd=4.1.2_approved_and_fixed&remaction=run&sharer_id=7 Unfortunately, I do not have "rights" to make this "public" without the need for a BZ login. Can one of our BZ admins make this happen? I've not found an option to enable this query for every BZ user even when they are not logged-in. The query Therefore I've put this query to the footer of every BZ webpage. When you go into your BZ preferences and then into your saved searches, maybe you can see a special option for oyur own queries. HTH Marcus Thanks for looking into this. I think the BZ admins can make a search public without the need for a BZ login, but I can't. Take a look at the "easy hacks" link on -- http://openoffice.apache.org/orientation/intro-development.html as an example. @Herbert, Rob: Do you you have maybe an idea how to reach this? Thanks Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: karma needed on a query
Am 10/15/2015 09:20 PM, schrieb Kay Schenk: The following query is being referenced in the release notes for 4.1.2 for "fixed issues"-- https://bz.apache.org/ooo/buglist.cgi?cmdtype=dorem&list_id=170710&namedcmd=4.1.2_approved_and_fixed&remaction=run&sharer_id=7 Unfortunately, I do not have "rights" to make this "public" without the need for a BZ login. Can one of our BZ admins make this happen? I've not found an option to enable this query for every BZ user even when they are not logged-in. The query Therefore I've put this query to the footer of every BZ webpage. When you go into your BZ preferences and then into your saved searches, maybe you can see a special option for oyur own queries. HTH Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Release status - Please test OpenOffice 4.1.2-RC2
Am 10/15/2015 10:50 AM, schrieb Pedro Lino: Bugs marked as RESOLVED FIXED must be set to VERIFIED or REOPENED. Note that many are still in RESOLVED FIXED state but have indeed been verified if you read the issue. In that case it is enough to change the issue status, but an extra verification is always helpful. I have Verified several Fixed bugs but only in Comments since I don't have permission to change Status. Do I need a special permission from someone or this is a bug in bugzilla? I've added you to the "canconfirm" and "qa-team" groups. I think you should be able to change the issue status now. If not, just tell me. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [RELEASE]: propose RC4 on revision 1587478
Am 04/17/2014 04:59 PM, schrieb Jürgen Schmidt: Hi, I would like to propose a new RC3 based on revision 1587478 of our AOO410 release branch. Integrated fixe for https://issues.apache.org/ooo/show_bug.cgi?id=124682 +1 The latest reported problems with digital signatures can be solved with setting an additional environment variable on non windows platforms. A wiki page will be created to describe in detail what the user have to do. and the release notes will be updated as well. For now you can view issue https://issues.apache.org/ooo/show_bug.cgi?id=124701 for some details. This looks like an simple and acceptable workaround for the Mac/Linux users. When I understand Herbert's last comment [1] correctly, then it sounds for me as a fix for the next release (4.1.1 or 4.2.0). [1] https://issues.apache.org/ooo/show_bug.cgi?id=124701#c9 Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [RELEASE]: propose AOO 4.1.0 RC
Am 04/02/2014 04:45 PM, schrieb Jürgen Schmidt: I hope that nobody have a problem with the revision number ...666 and the build date April 1th ;-) I find it funny and you can expect a very hot version ... What a mere chance. :-) Marcus On 4/2/14 3:16 PM, Jürgen Schmidt wrote: Hi, FOLLOW UP discussion please on the dev list!!! Last week I proposed a final schedule for our upcoming AOO 4.1 release. We are a little bit behind because the fact that we had to fix some further critical issues. Nevertheless I would like to propose a first RC based on revision 1583666 from the AOO410 branch. We spend a lot of time in preparing the RC in time and the upload is ongoing. The MacOS and Windows versions are already available and the Linux upload is still ongoing. But keep in mind the binaries are for convenience and the release relevant bits are the source release. The RC builds can be found as always under https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds An overview of the fixes issues, enhancements and tasks going into this release can be found under http://people.apache.org/~jsc/milestones/4.1.0-rc/AOO4.1.0_RC_fixes.html. I invite all volunteers to help with the verification of the fixed issues. Especially the issues related to translation updates/fixes should be verified by native speakers. A related RAT scan can be found under http://people.apache.org/~jsc/milestones/4.1.0-rc/AOO4.1.0_RAT_Scan.html I have also prepared patches (msp) for Windows and for the languages we have released with AOO 4.0.1. The patches are intended for private use only and of course for testing but not for the release. It's the first time that we prepared a complete set of patches and we have to test the functionality a little bit more. The related full install sets are prepared for patches in the future and can release patches in the future as well if they work as expected. By the way I have upgraded AOO 4.0.1 (en-US) on my Windows laptop with the msp to AOO 4.1 ;-) I plan to start a vote for this RC later today and let it run until Sunday night, means enough time to test and evaluate the bits careful. Linux binaries will be available tomorrow latest. We have not fixed and integrated all requested showstoppers because they were not all showstoppers from my perspective and we should take into account that we have limited resources in the project able to fix issues. We focused on issues that are obviously showstoppers and on those who are relevant for most of our users. Juergen - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [RELEASE]: refined AOO 4.1 beta schedule
Am 02/27/2014 04:50 PM, schrieb Jürgen Schmidt: Hi, we are still verifying some fixes to identify the Beta as real beta, means some branding elements, names etc. And we are working on some serious bugfixes that we have identified already. The current plan is to start the build tomorrow and do the upload over the weekend. That means we should have a RC for AOO 4.1 beta available at the beginning of next. The new icons are still not complete and I am not sure how we can or should continue here. Replacing them for the final release is probably not a good idea. Work remaining before beta 1) Defect verification 2) Release Notes check, update and finalize the release notes [1] 3) Communications Clarify the communication/promotion for the beta. For example how many users do we want to reach with the beta. 4) Release vote Based on this a possible schedule can be March 4th: availability of AOO 41. Beta RC + start vote March 10th: public availability of AOO 41. Beta (until March 31th) ...: additional snapshot builds based on the beta including showstopper fixes April 2th: availability of AOO 4.1 RC April 7th: public availability of AOO 4.1 Any opinions or feedback I'll try to make one day off to be available on March 10th the whole day, so we can be flexible with announcements and publications. Marcus [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Notes - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Wikis down
Am 02/17/2014 09:08 PM, schrieb jan i:
Actually we are back online !
We dont depend so much on miracles, but with only 4 staff to take care 150+
vm, things take time.
Infra only updates the status page, and leaves it to projects to inform
users, on top of that I posted a note on our ML.
Thanks a lot for your effort. I've removed the webpage hint.
Marcus
On 17 February 2014 20:42, Marcus (OOo) wrote:
Am 02/17/2014 07:34 PM, schrieb Rainer Bielefeld:
Hi all,
Wikis have been down for 2 days or so,
<http://monitoring.apache.org/status/>
shows critical for half the infrastructure, but latest news on Twitter
is "Feb 11: Great news for @theASF projects using GitHub!"
Sometimes miracles take a little longer, but (if no quick solution is
foreseeable) shouldn't there be some info for the users of the
infrastructure? And for the AOO users despairing of tons of not working
Wiki-Links on<https://www.openoffice.org/>, especially documentation? I
think the http://www.openoffice.org/ header ("Apache OpenOffice
The Free and Open Productivity Suite") should get a short hint like "Our
Wikis are temporarily down, please excuse us for inconvenience".
As a fast solution, I've updated the "contact_us" webpage with a hint that
Wiki is down and we are working on it. This should avoid user complains
about non-working Wiki.
Marcus
-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Wikis down
Am 02/17/2014 07:34 PM, schrieb Rainer Bielefeld:
Hi all,
Wikis have been down for 2 days or so,
<http://monitoring.apache.org/status/>
shows critical for half the infrastructure, but latest news on Twitter
is "Feb 11: Great news for @theASF projects using GitHub!"
Sometimes miracles take a little longer, but (if no quick solution is
foreseeable) shouldn't there be some info for the users of the
infrastructure? And for the AOO users despairing of tons of not working
Wiki-Links on <https://www.openoffice.org/>, especially documentation? I
think the http://www.openoffice.org/ header ("Apache OpenOffice
The Free and Open Productivity Suite") should get a short hint like "Our
Wikis are temporarily down, please excuse us for inconvenience".
As a fast solution, I've updated the "contact_us" webpage with a hint
that Wiki is down and we are working on it. This should avoid user
complains about non-working Wiki.
Marcus
-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Someone forgot to change the tip "openoffice.org" to "openoffice"
Fixed, thanks for the hint. Marcus Am 01/18/2014 09:06 PM, schrieb Marco A.G.Pinto: Hello! In the main site, when one hovers with the mouse over the "download" link at the top, it says "download openoffice.org" when the ".org" should be removed. Here is a screenshot: http://i.imgur.com/f2TCXn6.png Thanks! Kind regards, >Marco A.G.Pinto - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Some thoughts on quality
Am 08/14/2013 09:58 PM, schrieb Rob Weir: On Wed, Aug 14, 2013 at 3:37 PM, Marcus (OOo) wrote: Am 08/14/2013 09:01 PM, schrieb Raphael Bircher: Am 14.08.13 20:21, schrieb Rob Weir: On Wed, Aug 14, 2013 at 1:36 PM, Edwin Sharp wrote: Dear Rob The 4.0 release was too ambitious - we should advance in smaller steps. Nothing compares to general public testing - betas and release candidates should not be avoided. TestLink cases should be less comprehesive (in terms of feature coverage) and more stress testing oriented. The number to consider here is how many defects were found and fixed during the 4.0.0 testing, before the general public users had access? I assume it was quite substantial. If so, the TestLink usage was effective. In other words, we might have found fewer bugs without using it. In general, my feeling is that it's too early to do a retrospective and ask "what was good, what needs to be improved?" (to say it with SCRUM words ;-) ) Just after the first major release. Memories are still fresh and programmers are looking at the relevant code. This is the best time to answer these questions. We should look on the BZ query you have mentioned and see if there is one or more hotspots that should be improved fast. That's it. That would be fine. I'm not suggesting anything radical. Gradual, but constant improvements are the way to high quality. Then this should be sufficiant IMHO. This is important to keep in mind: we want to prevent or find more bugs, but we're not starting from zero. We're starting from a process that does a lot of things right. I like the idea of a public beta. But consider the numbers. The 40 or so regressions that were reported came from an install base (based on download figures since 4.0.0 was released) of around 3 million users. Realistically, can we expect anywhere near that number in a public beta? Or is it more likely that a beta program has 10,000 users or fewer? I don't know the answer here. But certainly a well-publicized and used beta will find more than a beta used by just a few hundred users. The public beta is from my point of view realy important. Even you have only 10'000 Downloads of a beta, you have normaly verry experianced Users there, like power users from Companies. They provide realy valua feedback. So from my point of view, this is one of the moast important changes we have to do. For all Feature release a beta version. And don't forget, people are realy happy to do beta tests. but many of them are maybe not willing to follow a mailing list. A public beta release is of course not the golden solution but could activate some power users that give us the feedback we want and need. So, +1 for going this way. After the 4.1 release is done we can see if this was much better - and ask ourself why? :-) But several of the bugs in 4.0.0 should never have made it to even a beta. For example, the very slow saving in Excel format. What happened there? Sure, this could be fixed later in the process, in a beta, or in a 4.0.1 as we're doing now. But this really should have been detected and fixed much earlier in the process. What are betas good for? Betas are good for expanding the set of configurations. Platforms, languages, extensions, etc.But the informal "tests" done by real users tend to be shallow. Also, we have no way of determining what the test coverage is. In particular we have no basis for telling the difference between the coverage of a 2 week beta versus a 4 week beta. But with out formal test cases we can easily look at how many test cases were executed. We could even look at code coverage if we wanted to. Maybe if there was a way to record what features beta testers were using... Or even have a little survey where they report what platform they ran on, etc. But very slow saving to XLS files? A defect like that should have been caught by us before a beta and before a RC. We shouldn't expect to find bugs like that in a beta. Of course. I've said nothing different. ;-) Finally, I think we can all point to a similar open source project that has numerous betas, but still suffers from poor quality. So a public beta, by itself, is not sufficient. We need some upstream improvements as well, I think. But we should do a beta as well. But aim to have the highest quality beta we can, right? Sure, the XLS bug has nothing to with "this wouldn't happen with a Beta". As I answered to Hagar this is one hotspot that should be looked at closer. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Some thoughts on quality
Am 08/14/2013 09:01 PM, schrieb Raphael Bircher: Am 14.08.13 20:21, schrieb Rob Weir: On Wed, Aug 14, 2013 at 1:36 PM, Edwin Sharp wrote: Dear Rob The 4.0 release was too ambitious - we should advance in smaller steps. Nothing compares to general public testing - betas and release candidates should not be avoided. TestLink cases should be less comprehesive (in terms of feature coverage) and more stress testing oriented. The number to consider here is how many defects were found and fixed during the 4.0.0 testing, before the general public users had access? I assume it was quite substantial. If so, the TestLink usage was effective. In other words, we might have found fewer bugs without using it. In general, my feeling is that it's too early to do a retrospective and ask "what was good, what needs to be improved?" (to say it with SCRUM words ;-) ) Just after the first major release. We should look on the BZ query you have mentioned and see if there is one or more hotspots that should be improved fast. That's it. This is important to keep in mind: we want to prevent or find more bugs, but we're not starting from zero. We're starting from a process that does a lot of things right. I like the idea of a public beta. But consider the numbers. The 40 or so regressions that were reported came from an install base (based on download figures since 4.0.0 was released) of around 3 million users. Realistically, can we expect anywhere near that number in a public beta? Or is it more likely that a beta program has 10,000 users or fewer? I don't know the answer here. But certainly a well-publicized and used beta will find more than a beta used by just a few hundred users. The public beta is from my point of view realy important. Even you have only 10'000 Downloads of a beta, you have normaly verry experianced Users there, like power users from Companies. They provide realy valua feedback. So from my point of view, this is one of the moast important changes we have to do. For all Feature release a beta version. And don't forget, people are realy happy to do beta tests. but many of them are maybe not willing to follow a mailing list. A public beta release is of course not the golden solution but could activate some power users that give us the feedback we want and need. So, +1 for going this way. After the 4.1 release is done we can see if this was much better - and ask ourself why? :-) Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Updating BZ versions for next releases
Am 08/05/2013 06:51 PM, schrieb Rob Weir: On Mon, Aug 5, 2013 at 12:42 PM, Marcus (OOo) wrote: Am 08/05/2013 06:31 PM, schrieb Rob Weir: On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo) wrote: Am 08/05/2013 05:47 PM, schrieb janI: On 5 August 2013 17:38, Rob Weirwrote: I'd like to update BZ to reflect the next release of AOO. Version are tracked in three different fields: Version, which currently allows the values "AOO 4.0.0" and "AOO410-dev" Target Milestone, which currently allows the values "AOO 4.0", "AOO 4.1" and "AOO PleaseHelp" Last Confirmation on, which currently allows the values "AOO 3.4.0", "AOO 3.4.1", and "AOO 4.0.0". I'd like to clean this up a little, as follows: 1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or 4.0.0. None of these versions are "end of life" so they should be allowed for new bug reports. +1 2) I don't see the purpose of "AOO PleaseHelp" as a milestone version. Are we overloading meaning in this field? If we really need track issues that need help we should define a keyword for this. So I'm inclined to delete this milestone version number. If it's possible to delete the item without to leave gaps in the issues itself then +1. 3) I'd also like to simplify the versions across the board to be just "3.4.1", "4.0.0", etc., without the "AOO" prefix. +1 4) For Last Confirmation On, I'd like to hide values except for 4.0. We should not be confirming bugs without testing on the most recent version. Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but confirmation should occur on 4.0. Since 3.4.0 and 3.4.1 (I actually thought it was only 3.4.1) are live version, which we support, all bugs reported there must also be tested there. I agree they should also be tested in 4.0, but not only in 4.0. So we would actually need a double confirmation, 3.4.x and 4.0 ? Current field is a single-selection drop down. BZ does allow multiple-selection fields, but I don't see any way to switch the type of a field once it has been used. In any case I'm not inviting debate of the process. I appreciate that You asked for feedback. ;-) I appreciate that some might wish that the QA volunteers spent twice as much time and tested on twice as many versions of AOO. But changing a BZ field obviously doesn't cause that to happen. My intent was merely to I don't wish this. If they do it, they do it on their own. I believe there is also a way sometimes to trust the user or developer when they choose 3.4.1 and 4.0.0 as confirmed versions. update the field to support the purpose the field was added in the first place, to track the most-recent version of AOO the bug was confirmed on. OK, looking at the title of the field then indeed only one version is possible. However, I still think there is a value add to have the confirmation that a bug is occurring in more than just the most recent version. It can be useful in some cases. If you can identify the last version that did not have the defect, and the first version that did have the defect, then you can narrow down the range of commits that could have caused the bug. Unfortunately I don't see an admin-accessible way to change the field type. In theory someone could work with Infra to get direct DB access and create a new multi-value field and then write some SQL to migrate the old values into the multi-value schema. OK, then this discussion can end here if we have a technical limit. But I'm not sure that would have much more value than noting these facts in a comment field. In terms of workflow, searching for all confirmed bugs that have not been tested with at least 3.4.0 is useful. It gives us a list of bugs that we should re-test. But I'm not sure why I would search for bugs that were confirmed in a specific old version like 3.4.0. I don't talked about searching for old bugs or restesting them. Just about the possibilitiy to give a fast and visible indication if it's a new bug or a regression. That's all. Marcus Right, to recognize a regression faster it should be possible to set the values to 3.4.1 and 4.0.0 (is it possible to enable multiselection for this field?). Then you can see on the first view that the issue is not a new thing in 4.0.0 but was already exisiting also in 3.4.1. 5) I'll add a new Target Milestone of "4.0.1" and Version of "4.0.1-dev" since it is likely that we will have a 4.0.1 release to address some of the defects that have been reported on 4.0.0. +1 Then we can separate easily: - fast fixed for 4.0.1 - general new things for 4.1.0 I'd love to hear your thoughts on this, even if it is just a quick +1. I'll hold off making any of thes
Re: Updating BZ versions for next releases
Am 08/05/2013 06:31 PM, schrieb Rob Weir: On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo) wrote: Am 08/05/2013 05:47 PM, schrieb janI: On 5 August 2013 17:38, Rob Weir wrote: I'd like to update BZ to reflect the next release of AOO. Version are tracked in three different fields: Version, which currently allows the values "AOO 4.0.0" and "AOO410-dev" Target Milestone, which currently allows the values "AOO 4.0", "AOO 4.1" and "AOO PleaseHelp" Last Confirmation on, which currently allows the values "AOO 3.4.0", "AOO 3.4.1", and "AOO 4.0.0". I'd like to clean this up a little, as follows: 1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or 4.0.0. None of these versions are "end of life" so they should be allowed for new bug reports. +1 2) I don't see the purpose of "AOO PleaseHelp" as a milestone version. Are we overloading meaning in this field? If we really need track issues that need help we should define a keyword for this. So I'm inclined to delete this milestone version number. If it's possible to delete the item without to leave gaps in the issues itself then +1. 3) I'd also like to simplify the versions across the board to be just "3.4.1", "4.0.0", etc., without the "AOO" prefix. +1 4) For Last Confirmation On, I'd like to hide values except for 4.0. We should not be confirming bugs without testing on the most recent version. Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but confirmation should occur on 4.0. Since 3.4.0 and 3.4.1 (I actually thought it was only 3.4.1) are live version, which we support, all bugs reported there must also be tested there. I agree they should also be tested in 4.0, but not only in 4.0. So we would actually need a double confirmation, 3.4.x and 4.0 ? Current field is a single-selection drop down. BZ does allow multiple-selection fields, but I don't see any way to switch the type of a field once it has been used. In any case I'm not inviting debate of the process. I appreciate that You asked for feedback. ;-) > I appreciate that some might wish that the QA volunteers spent twice as much time and tested on twice as many versions of AOO. But changing a BZ field obviously doesn't cause that to happen. My intent was merely to I don't wish this. If they do it, they do it on their own. I believe there is also a way sometimes to trust the user or developer when they choose 3.4.1 and 4.0.0 as confirmed versions. update the field to support the purpose the field was added in the first place, to track the most-recent version of AOO the bug was confirmed on. OK, looking at the title of the field then indeed only one version is possible. However, I still think there is a value add to have the confirmation that a bug is occurring in more than just the most recent version. Marcus Right, to recognize a regression faster it should be possible to set the values to 3.4.1 and 4.0.0 (is it possible to enable multiselection for this field?). Then you can see on the first view that the issue is not a new thing in 4.0.0 but was already exisiting also in 3.4.1. 5) I'll add a new Target Milestone of "4.0.1" and Version of "4.0.1-dev" since it is likely that we will have a 4.0.1 release to address some of the defects that have been reported on 4.0.0. +1 Then we can separate easily: - fast fixed for 4.0.1 - general new things for 4.1.0 I'd love to hear your thoughts on this, even if it is just a quick +1. I'll hold off making any of these changes until this time Thursday. +1 to all except 4). I agree with Jan. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Updating BZ versions for next releases
Am 08/05/2013 06:26 PM, schrieb Rob Weir: On Mon, Aug 5, 2013 at 12:06 PM, Andrea Pescetti wrote: On 05/08/2013 Rob Weir wrote: I'd love to hear your thoughts on this, even if it is just a quick +1. Here's my quick +1, with a question: when I report a bug (typically a small regression) that I would like to see fixed in the possible 4.0.1 release, shall I already set the Target to 4.0.1? In ancient times this was left to the developer who had accepted the bug, but we are now less strict in Bugzilla usage. And setting the target to 4.0.1 would help in evaluating if/when we need a 4.0.1. That question probably deserves its own thread. IMHO we need to decide what a 4.0.1 is: 1) We might want to have it contain fixes for only the most urgent bugs. We could include new translations that are available as well. If we make that restriction then the QA impact is less. We don't need to do a complete regression test pass. If we did that then we could use the "release blocker" field to track these issues. We'd only fix issues in 4.0.1 that have been discussed as release blockers. 2) Or we could open 4.0.1 up to all changes, in which case new bugs can be introduced anywhere, possible translation impact, etc. Personally I think 4.0.1 should be more like #1 -- strictly limited to specific bug fixes. We then use 4.1 (the trunk) for non-urgent fixes. OK, before I put in my 2 cents also here. Rob or Andrea, will you open a new thread? Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Updating BZ versions for next releases
Am 08/05/2013 05:47 PM, schrieb janI: On 5 August 2013 17:38, Rob Weir wrote: I'd like to update BZ to reflect the next release of AOO. Version are tracked in three different fields: Version, which currently allows the values "AOO 4.0.0" and "AOO410-dev" Target Milestone, which currently allows the values "AOO 4.0", "AOO 4.1" and "AOO PleaseHelp" Last Confirmation on, which currently allows the values "AOO 3.4.0", "AOO 3.4.1", and "AOO 4.0.0". I'd like to clean this up a little, as follows: 1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or 4.0.0. None of these versions are "end of life" so they should be allowed for new bug reports. +1 2) I don't see the purpose of "AOO PleaseHelp" as a milestone version. Are we overloading meaning in this field? If we really need track issues that need help we should define a keyword for this. So I'm inclined to delete this milestone version number. If it's possible to delete the item without to leave gaps in the issues itself then +1. 3) I'd also like to simplify the versions across the board to be just "3.4.1", "4.0.0", etc., without the "AOO" prefix. +1 4) For Last Confirmation On, I'd like to hide values except for 4.0. We should not be confirming bugs without testing on the most recent version. Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but confirmation should occur on 4.0. Since 3.4.0 and 3.4.1 (I actually thought it was only 3.4.1) are live version, which we support, all bugs reported there must also be tested there. I agree they should also be tested in 4.0, but not only in 4.0. So we would actually need a double confirmation, 3.4.x and 4.0 ? Right, to recognize a regression faster it should be possible to set the values to 3.4.1 and 4.0.0 (is it possible to enable multiselection for this field?). Then you can see on the first view that the issue is not a new thing in 4.0.0 but was already exisiting also in 3.4.1. 5) I'll add a new Target Milestone of "4.0.1" and Version of "4.0.1-dev" since it is likely that we will have a 4.0.1 release to address some of the defects that have been reported on 4.0.0. +1 Then we can separate easily: - fast fixed for 4.0.1 - general new things for 4.1.0 I'd love to hear your thoughts on this, even if it is just a quick +1. I'll hold off making any of these changes until this time Thursday. +1 to all except 4). I agree with Jan. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
