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 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 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)marcus.m...@wtnet.de 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 onhttps://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: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 el...@mail-page.com 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 05:47 PM, schrieb janI: On 5 August 2013 17:38, Rob Weirrobw...@apache.org 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
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 Pescettipesce...@apache.org 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 06:51 PM, schrieb Rob Weir: On Mon, Aug 5, 2013 at 12:42 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/05/2013 06:31 PM, schrieb Rob Weir: On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/05/2013 05:47 PM, schrieb janI: On 5 August 2013 17:38, Rob Weirrobw...@apache.orgwrote: 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 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
