Re: [Libreoffice-qa] Regressions in Open Source projects ...
On Thu, 2012-03-15 at 21:22 +0100, Petr Mladek wrote: > > Actually I was talking about SUSE LibreOffice for Windows (which is > > apparently a one-off unsupported release created for the Intel AppUp > > store) :) Nah - SUSE will be maintaining that with our stable release. Though of course it doesn't come with enterprise support, and problem temporary fix builds and so on :-) It is certainly true that it is currently 3.4.2 based but that should be updated to something 3.4.5/6 based soonish as we pull up our customers to that [ though this version is only a base - the build will include a number of additional back-ports, other misc. fixes, different compile options etc. ]. To understand SUSE LibreOffice vs. vanilla LibreOffice the best analogy is something like the SUSE / RedHat 'Enterprise' linux kernels - these become increasingly less vanilla from release time out with tons of back-ported bits. Wrt. our plans for a SUSE / 3.5 based release, those are not public that I know of; but should happen in due course. The team is even now working hard to chew through regressions, and check that every L3 customer bug we've fixed in the past does not regress in our 3.5.x base - that of course results in lots of fixes & improvements going into the libreoffice-3-5 branch I hope. All the best, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Regressions in Open Source projects ...
Rainer Bielefeld wrote: > d) No LibO version shows line width in Chart legend correctly > because of "Bug 31551 Lines in legend not shown with current width", > so I have to use OOo 3.1.1 for some needs (inherited problem, 3.3 > has the same problem like LibO). But unfortunately OOo 3.1.1 is very > unstable with my master documents edited with LibO. > Hi Rainer, Bubli fixed that meanwhile on master - any chance you could test whether http://dev-builds.libreoffice.org/daily/Win-x86@7-MinGW/master/current/ has that fixed for real? The fix then looks benign enough to be cherry-picked into -3-5. Cheers, -- Thorsten pgpOcspbZqxOr.pgp Description: PGP signature ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Regressions in Open Source projects ...
Thorsten Behrens schrieb: Bubli fixed that meanwhile on master - any chance you could test whether Hi, yes, I will do a test soon. Thx for hint Rainer ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Regressions in Open Source projects ...
Hi Rainer, all, On Fri, Mar 16, 2012 at 07:21:15AM +0100, Rainer Bielefeld wrote: > a) Regression "Bug 47096 EDITING: Alt + Drag and Drop for complete > rows impossible in particular documents" frequently forces me to use > 3.4.5. I had a short look at this one as a exemplary post-mortem (the bug seems to be assumed fixed from the developer side). What we have here is a bug that was introduced on the release branch (as it wasnt in the beta), which is not good. But such things can and will happen, the question is how to handle them quickly. So what can we do better here? A casual (actually I have no idea about this code domain) digging through the history shows that this regression was likely introduced by: http://cgit.freedesktop.org/libreoffice/core/commit/?id=a00c5917a8deb465cc1322e14a81340f9d69 because that last touched related code areas (so this was neither adding nor removing a regression, but exchanging one for another). So how can we improve detecting such things on the release branch? git log libreoffice-3.5.0.2..libreoffice-3-5-1 tells me that there have been 213 commits between 3.5.0 final and 3.5.1 final, which suggest a rather limited scope of areas touched. IMHO it would make sense to focus manual testing for the touched areas of code. Doing a: for d in `find . -maxdepth 1 -mindepth 1 -type d`; do echo `git log --pretty=oneline libreoffice-3.5.0.2..HEAD $d|wc -l` $d;done|sort -n|tail shows the following stats: 5 ./svx (GUI) 7 ./officecfg (configuration/settings) 7 ./oox (docx filters etc.) 7 ./writerfilter (Writer) 9 ./solenv (build/installation) 12 ./scp2 (installation) 13 ./extensions (various) 15 ./connectivity (Base) 22 ./sc (Calc) 39 ./sw (Writer) If we could coordinate those interested in a bit more systematic manual testing to look at these areas for micro releases, to prevent "fixed a regression, introduced a regression scenarios", that would be awesome. Since the number of changes in one specific area of code in rather limited, we then can: - pinpoint the change (and the developer) that causes the trouble quickly - reject fixes that cause another regression - consciously make a choice to include a fix that causes a minor regression, when it fixes a major one and there is no good alternative Divide and conquer is the way to go here. With the 22 commits in Calc for example this should be something one volunteer should be able to comfortably have an eye on over the ~one month period between both releases. Writer (most likely because of Michael Stahls regression fixing rampage) currently might need two people volunteering. And obviously, the number of commits will likely slow down now after 3.5.1. So dear QA-list members: Anyone interested in picking this up for one application? Who would like to do it for Writer? Who for Calc? > b) Regression "Bug 45385 EDITING: Copy Paste formula to different > document adds source document filename to references" (what even > isn't accepted as a bug, but will be a showstopper for me to use > LibO if no solution will be found) frequently forces me to use > 3.4.5. So far this is not a bug, but intended behaviour. As that I wouldnt consider it a regression or an indication of QA problems. It indicates something else though: we had a failure to communicate there, the intended change of behaviour would have needed to be communicated clearly and before the actual change was made. This is something we need to improve upon, and we need to find a good way to make this information accessable. This could be done on the dev ML, but given the noise on it a bug filed for this would be even better. I am open to other ways to improve communication there, if proposed. > c) 3.4 has no working e-mail mail merge, so I have to use 3.5 for this. 3.4 is history and we dont work like that anymore. > d) No LibO version shows line width in Chart legend correctly > because of "Bug 31551 Lines in legend not shown with current width", > so I have to use OOo 3.1.1 for some needs (inherited problem, 3.3 > has the same problem like LibO). But unfortunately OOo 3.1.1 is very > unstable with my master documents edited with LibO. Another pre-3.5 regression from when our workflow was suboptimal. Yes, we got to fix those, but it is even more important that we make sure now to not add regressions. Preventing a regression is so much easier than fixing one. Thus preventing regressions helps us find the resources to fix regressions that did slide in while fixing bugs and adding features. > May be you understand why I have some empathy for users fulminating > on mailing lists and why I never recommended LibO to friends without > many reservations? I totally have for users using 3.4. But empathy shouldnt make us stray from rational decisionmaking. > But we should use our time to find and eliminate these problems > instead of whining, thanks to all pest control helpers. Indeed! So: Im looking forward to voluteers interested in adopting an area of cod
Re: [Libreoffice-qa] minutes of LibreOffice QA call 2012-03-09 15:00 UTC
On Fri, Mar 09, 2012 at 06:42:45PM +0100, Bjoern Michaelsen wrote: > AA- Set Cor up with the Community/Forum maintainers at the distros > to better propagate Hackfests, Bug Hunting Sessions etc. > (Bjoern, Petr, Caolan, others?) Done (my part of it). Best, Bjoern ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Regressions in Open Source projects ...
Rainer Bielefeld schrieb: yes, I will do a test soon. Hi, I still suffer from "Bug 44489 - MinGW: Will not launch", so I will have to wait for the next Master from other source. CU Rainer ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] minutes of LibreOffice QA call 2012-03-09 15:00 UTC
Hi, On Fri, Mar 09, 2012 at 06:42:45PM +0100, Bjoern Michaelsen wrote: > AA- copypaste existing manual test as a one off for 3.5/Precise (Bjoern) > AA- Check if test documents are URLs properly distributed to Checkbox > (Bjoern) Just discussed this with Nicholas Skaggs, the deadline for this is Tuesday(*), so any help with this is welcome. Essentially all that needs to be done is copying of the testcase with a little decoration: http://paste.ubuntu.com/886661/ If you want to help out, Nicholas is around as balloons on IRC (freenode). I will jump in on Monday, if needed. Best, Bjoern (*) it sneaked itself there, it was originally assumed to be Friday ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
[Libreoffice-qa] [ANN] LibreOffice 3.4.6 RC2 available
Dear Community, The Document Foundation is happy to announce the second release candidate of LibreOffice 3.4.6. The upcoming 3.4.6 will be the sixth in a series of frequent bugfix releases for our 3.4 code line. Please be aware that LibreOffice 3.4.6 RC2 is not yet ready for production use, you should continue to use LibreOffice 3.4.5 for that. The release is available for Windows, Linux and Mac OS X from our QA builds download page at http://www.libreoffice.org/download/pre-releases/ Should you find bugs, please report them to the FreeDesktop Bugzilla: https://bugs.freedesktop.org For other ways to get involved with this exciting project - you can e.g. contribute code: https://www.libreoffice.org/get-involved/developers/ translate LibreOffice to your language: http://wiki.documentfoundation.org/Translation_for_3.4 or help with funding our operations: http://challenge.documentfoundation.org/ A list of known issues with 3.4.6 RC2 is available from our wiki: http://wiki.documentfoundation.org/Releases/3.4.6/RC2 Please find the list of changes against LibreOffice 3.4.6 RC1 here: http://download.documentfoundation.org/libreoffice/src/bugfixes-libreoffice-3-4-6-release-3.4.6.2.log Let us close again with a BIG Thank You! to all of you having contributed to the LibreOffice project - this release would not have been possible without your help. Yours, The Document Foundation Board of Directors pgpBrn1zWmp8X.pgp Description: PGP signature ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Regressions in Open Source projects ...
Bjoern Michaelsen schrieb: Hi, you wrote some similar ideas I had, but I was doubtful concerning viability. May be we can discuss some suggestions during the next QA call, I will be prepared. If we would have a branch WIN build every week, I would find lots of Bugs (if we have bugs), and some others might be willing to use those builds for their daily work, too. And the communication problem already has been discussed without results. May be some small expert teams could assist the developers if they get information concerning panned changes in time and can contribute their ideas and concerns. A general discussion of everything would jam all progress :-/ Best regards Rainer ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Regressions in Open Source projects ...
Hey all, I did not want to answer nut since you chose mainly my commits here is a short reply. > On Fri, Mar 16, 2012 at 07:21:15AM +0100, Rainer Bielefeld wrote: >> a) Regression "Bug 47096 EDITING: Alt + Drag and Drop for complete >> rows impossible in particular documents" frequently forces me to use >> 3.4.5. > > I had a short look at this one as a exemplary post-mortem (the bug seems to be > assumed fixed from the developer side). What we have here is a bug that was > introduced on the release branch (as it wasnt in the beta), which is not good. > But such things can and will happen, the question is how to handle them > quickly. So what can we do better here? > > A casual (actually I have no idea about this code domain) digging through the > history shows that this regression was likely introduced by: > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=a00c5917a8deb465cc1322e14a81340f9d69 The correct commit is http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5-0&id=49a1737b7d3d61304e749c6c164165b8bf68790e While is not good that this commit introduced a new regression it was fixing several problems and I was testing copy/paste (the only know bug problem area at this point) and did not find any problems. > > because that last touched related code areas (so this was neither adding nor > removing a regression, but exchanging one for another). So how can we improve > detecting such things on the release branch? No it is not that easy. This commit fixed several crashes and problems in the copy/paste code. We will from time to time get such regressions since it is nearly impossible to find all affected code paths in our highly coupled code. This has been introduced somewhere in one of the betas and has not been marked as serious for a long time. > > git log libreoffice-3.5.0.2..libreoffice-3-5-1 > > tells me that there have been 213 commits between 3.5.0 final and 3.5.1 > final, which suggest a rather limited scope of areas touched. IMHO it would > make sense to focus manual testing for the touched areas of code. Doing a: > > for d in `find . -maxdepth 1 -mindepth 1 -type d`; do echo `git log > --pretty=oneline libreoffice-3.5.0.2..HEAD $d|wc -l` $d;done|sort -n|tail > > shows the following stats: > > 5 ./svx (GUI) > 7 ./officecfg (configuration/settings) > 7 ./oox (docx filters etc.) > 7 ./writerfilter (Writer) > 9 ./solenv (build/installation) > 12 ./scp2 (installation) > 13 ./extensions (various) > 15 ./connectivity (Base) > 22 ./sc (Calc) > 39 ./sw (Writer) > > If we could coordinate those interested in a bit more systematic manual > testing > to look at these areas for micro releases, to prevent "fixed a regression, > introduced a regression scenarios", that would be awesome. Since the number of > changes in one specific area of code in rather limited, we then can: > > - pinpoint the change (and the developer) that causes the trouble quickly > - reject fixes that cause another regression > - consciously make a choice to include a fix that causes a minor regression, > when it fixes a major one and there is no good alternative > > Divide and conquer is the way to go here. With the 22 commits in Calc for > example this should be something one volunteer should be able to comfortably > have an eye on over the ~one month period between both releases. Writer (most > likely because of Michael Stahls regression fixing rampage) currently might > need two people volunteering. And obviously, the number of commits will likely > slow down now after 3.5.1. IMHO the way to go is automated testing and adding a test case for fixed bugs im possible. I fear that most of the time not even devs know all affected features so how should a normal user or qa person know what to test. > > So dear QA-list members: > Anyone interested in picking this up for one application? > Who would like to do it for Writer? > Who for Calc? > >> b) Regression "Bug 45385 EDITING: Copy Paste formula to different >> document adds source document filename to references" (what even >> isn't accepted as a bug, but will be a showstopper for me to use >> LibO if no solution will be found) frequently forces me to use >> 3.4.5. > > So far this is not a bug, but intended behaviour. As that I wouldnt consider > it > a regression or an indication of QA problems. It indicates something else > though: we had a failure to communicate there, the intended change of > behaviour > would have needed to be communicated clearly and before the actual change was > made. This is something we need to improve upon, and we need to find a good > way > to make this information accessable. This could be done on the dev ML, but > given the noise on it a bug filed for this would be even better. I am open to > other ways to improve communication there, if proposed. The old behavior while making sense in some corner cases was build on a broken design. Even the OOo Calc devs knew that and added a big warning in the code and had
Re: [Libreoffice-qa] minutes of LibreOffice QA call 2012-03-09 15:00 UTC
Thanks to a brave ubuntu community member, kaldor, these got entered.. I just pushed the revision, so they should be included for beta2 testing. We ported 34 tests -- we left out the "general" tests, as they mostly didn't apply for our purposes. Thanks! Nicholas On 03/16/2012 02:41 PM, Bjoern Michaelsen wrote: > Hi, > > On Fri, Mar 09, 2012 at 06:42:45PM +0100, Bjoern Michaelsen wrote: >> AA- copypaste existing manual test as a one off for 3.5/Precise (Bjoern) >> AA- Check if test documents are URLs properly distributed to Checkbox >> (Bjoern) > Just discussed this with Nicholas Skaggs, the deadline for this is Tuesday(*), > so any help with this is welcome. Essentially all that needs to be done is > copying of the testcase with a little decoration: > > http://paste.ubuntu.com/886661/ > > If you want to help out, Nicholas is around as balloons on IRC (freenode). I > will jump in on Monday, if needed. > > Best, > > Bjoern > > (*) it sneaked itself there, it was originally assumed to be Friday ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Regressions in Open Source projects ...
Hi, On Fri, Mar 16, 2012 at 08:30:50PM +0100, Markus Mohrhard wrote: > The correct commit is > http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5-0&id=49a1737b7d3d61304e749c6c164165b8bf68790e > > While is not good that this commit introduced a new regression it was > fixing several problems and I was testing copy/paste (the only know > bug problem area at this point) and did not find any problems. Proofs my "no domain knowledge" claim quite nicely. ;) > No it is not that easy. This commit fixed several crashes and problems > in the copy/paste code. We will from time to time get such regressions > since it is nearly impossible to find all affected code paths in our > highly coupled code. This has been introduced somewhere in one of the > betas and has not been marked as serious for a long time. Right. Still I think we can do better there. I am thinking about getting communication channels in place between development and testers to filter the out the 40.000ft view on changes. We "only" has 213 changes between 3.5.0 and 3.5.1 so a hint like "we tweaked on Copy/Paste in Calc, please torture that a bit to see if you find any regressions". Incidentally, we could make that a drive-by exercise in adding testcases to Litmus (ideally with a reference to the bugs fixed). ;) > IMHO the way to go is automated testing and adding a test case for > fixed bugs im possible. I fear that most of the time not even devs > know all affected features so how should a normal user or qa person > know what to test. I dont think I can agree here. Getting automated tests is good and nice, but it will never cover the whole story. Esp. things like Cut-n-Paste, which might be platformdependant and only show trouble when used in a real environment and not some cuddly headless testcase. The same goes for many other topics: - pretty much all of UI - printing - window management interaction - ... > And some more general remarks. > I think it was always known that the .0 release will still contain > some bugs and maybe the .1 release too. I think we are doing a great > job in the 3-5 release in fixing the serious bugs so that 3.5.2 is > already more stable than 3.4.5 or 3.4.6 (at least in calc). For > example my query for calc bugs shows no serious calc bug that is open > and that can be fixed for 3.5.2. Totally agree: 3.5 is an awesome series of our product. > What is annoying me is the steady complains about every changed > feature and fixed bug as making it worse. We sometimes need to change > the behavior a bit to fix bugs. Yes, that is true and development should not lose inertia for this. But we need to get this communicated out of development if such changes of behaviour happen, that _is_ essential. A non-developer will absolutely get lost on the noisy and messy bazaar that is the development mailinglist. We need to find a way to provide "the outside world" with a 40.000ft view of what is going on without burdening ourselves too much. > Instead of immediately screaming I would love to see some more constructive > critisism especially here on the qa-list instead of indirectly saying that > the devs ruined the release with this change. I will now stop here. If you think the qa-list is troublesome, I urge you to talk to a selection of random endusers. The qa-list is tame in comparison. But a lot of that is mitgated by simply having that documented (one line in the release notes, or better yet a bug on bugzilla). An enduser that went through the trouble of filing a bug is not exactly happy when his work (bugfiling) is swept away with "yeah, we actually intended that, but never bothered to tell anyone" (his perspective). Keep in mind that for every good enduser who filed a bug, there are 100 who do not, but rant about it on twitter instead. Having such things documented (release notes or whatever) helps in multiple ways: - Nobody reads the release notes, but at least the reporter of the bug knows he _could_ have looked there - bugwranglers have it a lot easier to manage reports, when they can refer to the release notes Having too many "false positives" i.e. bug reports about intended changes wastes a lot of time: the time of the reporter (reporters are possible future libreoffice-qa volunteers), the time of the bugwranglers, the time of the developers. And it might make us miss the important bugs in the mud. This is why getting this documented early is so important. Also, we need to get more serious testing on master going and raise the expectations on its quality. Master has a decent quality now, but I feel we are still suffering from the quality of the 3.4 days. The perception that master is ok to be broken is dangerous as it might lead to severe miscommunication: - development does an intended change - testers even see and ignore it assuming it only to be transitional (as sideeffect of the low expectations on master) - upon release, we get a sudden "hey, why wasnt that fixed?" confrontation
