Re: [Libreoffice] minutes of ESC call ...
Hi Bjoern, Bjoern Michaelsen wrote on 21-09-16 18:45: > Well, my point is if we make that an explicit requirement (e.g. "properly > triaged bugs need to be checked for if they are crossplatform or appear on > just > one") the net effects will be that devs dont yet look at the issue as it is > not > properly triaged. Sure. Now I do not support the idea that 'being proper triaged' is a prerequisite before developers will/may look at reports. Apart from that, the repeated example of crossplatform doesn't seem the most exited example of proper triage to me. Details of the reason of the bug, clear summary (finding, recognizing), component, duplicates (may ~indicate importance) regressions (user expectations, statistics), bibisection come to my mind much earlier. > [...] Making every bug perfectly triaged on every > detail before a dev sees it will waste resources, while just giving devs the > freedom to push issues back quickly to NEEDINFO with specific details on what > exactly they would like to know beyond basic triage makes for a much more > targeted triage. Sure, my point is that triage is useful for QA and devs. And indeed in a situation that looks as if there's not really enough hands to confirm all reports, let alone do proper triage where it would be good, let alone to do useful clean ups and in depth investigations on certain areas.., spending too many words on what/how the prefect route & handling is, seems a bit superfluous ;) So basically I don't see where we disagree :) Ciao - Cor -- Cor Nouws GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28 A038 E49D 7365 B134 80A6 - vrijwilliger http://nl.libreoffice.org - volunteer http://www.libreoffice.org - The Document Foundation Membership Committee Member ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
Hi, On Wed, Sep 21, 2016 at 11:33:28AM +0200, Cor Nouws wrote: > And then when the bug status also support QA work, more bugs will be > well triaged and clean, and easy to pick and understand by developers ;) > So both are valid. > > And what I read from Árons mail: just New is not enough for QA to see > that a bug is properly triaged. Well, my point is if we make that an explicit requirement (e.g. "properly triaged bugs need to be checked for if they are crossplatform or appear on just one") the net effects will be that devs dont yet look at the issue as it is not properly triaged. However, platformdependant bugs are common enough that we can optimistically assume a bug to be crossplatform by default without too much hurt. If that assumption fails (rarely), a sane dev will notice they cant reproduce, mention in a comment, move it to NEEDINFO asking to be better triaged and move on. > I bet you that there are many many bugs confirmed and set to New, to > keep the number of unconfirmed low, but where no or hardly any real > triage has been done. As long as devs are not complaining, I think this is ok. FWIW, if I run in a interesting undertriaged bug, I: - give it a try with whatever info is there - triage what I need in addition, but only when I feel like it - if Im not interested the in the needed additional info, I explicitly state what I miss in a comment, put it back to NEEDINFO and move on. > Nice challenge to find those and make sure the information in the > reports is used at it's best. Not all triage info is needed for devs in all cases. Good triage improves chances of a bug being picked up by a dev in general, but that is not a binary "triaged"/"not triaged" thing. Making every bug perfectly triaged on every detail before a dev sees it will waste resources, while just giving devs the freedom to push issues back quickly to NEEDINFO with specific details on what exactly they would like to know beyond basic triage makes for a much more targeted triage. Of course, to have a specific issues that somebody cares about being fixed, providing as much triage upfront before even explicitly requested by a dev is still an excellent strategy[1]. This is because I (and I assume others too) look at bibisected bugs a lot more often and longer than at other regressions, and at regressions a lot longer than at other confirmed bugs, etc. Best, Bjoern [1] Still no guarantees on being solved by volunteers obviously. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
Áron Budea wrote on 21-09-16 10:25: > On Wednesday, September 21, 2016 01:11 CEST, > wrote: >> Bug states should support the workflow to get the bug fixed -- not the other >> way around. And then when the bug status also support QA work, more bugs will be well triaged and clean, and easy to pick and understand by developers ;) So both are valid. And what I read from Árons mail: just New is not enough for QA to see that a bug is properly triaged. I bet you that there are many many bugs confirmed and set to New, to keep the number of unconfirmed low, but where no or hardly any real triage has been done. Nice challenge to find those and make sure the information in the reports is used at it's best. > Nevertheless, I agree that effort is better spent elsewhere than pursuing > really obscure bugs, it seems to be something where careful prioritization is > important. Not always easy to understand what is obscure and if that makes issues less relevant. It's always good to see when developers, for whatever reason, pick up 'minor' issues. Ciao - Cor -- Cor Nouws GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28 A038 E49D 7365 B134 80A6 - vrijwilliger http://nl.libreoffice.org - volunteer http://www.libreoffice.org - The Document Foundation Membership Committee Member ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
Hi, On Wednesday, September 21, 2016 01:11 CEST, "Bjoern Michaelsen" wrote: > Bug states should support the workflow to get the bug fixed -- not the other > way around. OS crosschecking is irrelevant in more than 90% of cases for the > work of a dev to start working on it. While regression info is quite helpful, > very often it is provided already by the initial report even. Both are not > reasons for devs to punt on the issue solely because of this -- thus, because > bug states should support workflows and not the other way around, not to have > yet-another-state and just have devs assume a crossplatform non-regression by > default. Regardless whether there is a separate status for "triaged" bugs or not, the mentioned actions only involve QA, and no developer activity. Thanks for the feedback, though, it's helpful to know what is worthwhile to spend time on. My original point was that the keyword asking for developer advice should not be restricted to UNCONFIRMED bugs if confirmed bugs don't have the requirement of reproducibility by QA. Nevertheless, I agree that effort is better spent elsewhere than pursuing really obscure bugs, it seems to be something where careful prioritization is important. Cheers, Aron ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
Hi, On Wed, Sep 21, 2016 at 12:24:37AM +0200, Áron Budea wrote: > I'd consider a bug triaged with the following steps also done, which are > rarely > done when the bug is set to NEW: > -check in other OSes, > -check if bug is regression. > > Yes, NEW means a developer can start working on it, but there should be a > status > meaning a bug requires no further QA attention (except bibisecting), so in my > book NEW doesn't mean triaged in itself. Bug states should support the workflow to get the bug fixed -- not the other way around. OS crosschecking is irrelevant in more than 90% of cases for the work of a dev to start working on it. While regression info is quite helpful, very often it is provided already by the initial report even. Both are not reasons for devs to punt on the issue solely because of this -- thus, because bug states should support workflows and not the other way around, not to have yet-another-state and just have devs assume a crossplatform non-regression by default. > The problem with independent confirmations only is that the status is hardly > different from UNCONFIRMED. Assuming QA tried and couldn't reproduce the > issue, > the bug is likely hard to reproduce, and setting to NEEDINFO won't help, as > the > reporter won't know what else to add, and it's a developer who can determine > what kind of further information is needed, and the steps to acquire it. That might be so, but spending developer ressources on the kinds of obscure bugs that cant be triaged by the projects QA ressources isnt a wise choice either. If users cant properly triage a bug with the help of projects QA ressources and there is no volunteer dev jumping on it on own initiative, there are various L3 support options welcoming to help them out. Best, Bjoern ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
Hi, On Tuesday, September 20, 2016 11:18 CEST, "Bjoern Michaelsen" wrote: > NEW _should_ mean triaged for all matters. That it is not called the more > descriptive TRIAGED (like it is on e.g. launchpad) is due to historic reasons. > A bug on bugs.documentfoundation.org should be in NEW only if a developer > could > start working on it. Otherwise it should be in UNCOFIRMED or NEEDINFO (as > should be for 101898: It was independently confirmed, but there still isnt a > reliable reproduction scenario that allows a developer to work on it). > > In general, bug states should be a rather clear mapping to which group of > people is responsible to take it to the next step: I'd consider a bug triaged with the following steps also done, which are rarely done when the bug is set to NEW: -check in other OSes, -check if bug is regression. Yes, NEW means a developer can start working on it, but there should be a status meaning a bug requires no further QA attention (except bibisecting), so in my book NEW doesn't mean triaged in itself. Another important distinction: any interested contributor having the latest LibreOffice version can confirm/unconfirm a bug, but more experience and preparation is required to further triage it. The problem with independent confirmations only is that the status is hardly different from UNCONFIRMED. Assuming QA tried and couldn't reproduce the issue, the bug is likely hard to reproduce, and setting to NEEDINFO won't help, as the reporter won't know what else to add, and it's a developer who can determine what kind of further information is needed, and the steps to acquire it. Thus bug 101898 still needs attention from a developer (if a reporter can debug that's a nice bonus, but not a realistic expectation). Additionally, at the time there are at least two interested people willing to provide additional information. When a developer picks up the bug later, there might be none. Thus a keyword should exist to denote that a bug needs developer attention outside the regular workflow. Thanks, Aron P.S.: subject orrected ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
On Wed, 2012-02-01 at 09:16 +0100, David Tardon wrote: > Hi, > > I created a wiki page for cppunit at > http://www.freedesktop.org/wiki/Software/cppunit . I am also going to > notify the Fedora maintainer(s) of cppunit that the project is alive > again :) Perhaps it would be good to add a point on http://www.freedesktop.org/wiki/Software ? Terry. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
2012/2/1 Stephan Bergmann : > On 01/27/2012 04:44 PM, Markus Mohrhard wrote: >>> >>> * unit test framework issues (Markus) >>> + we are missing an important feature >>> + cppunit development appears dead/stalled for 2+ yrs >>> + but we support system-cppunit >>> + can we not just declare ourselves the new up-stream >>> for cppunit (Lionel) >>> + requiring an internal cppunit not a big deal ? (Norbert) >>> + always internal one for dbgutil anyway (Markus) >>> + three options: (Stephan) >>> 1. always use internal / patched version >>> 2. there is a cppunit2 in Launchpad >>> + is it compatible ? or even more active ? >>> 3. re-evaluate whether we need cppunit, or something >>> else: google stuff eg. 'testing framework' >>> + looked into cppunit2 (Markus) >>> + stopped development at same time ~2009 >>> + project dead too. >>> + prefer our own version, or switch to new framework >>> for integration tests (Markus) >>> AA: + create new cppunit repository at freedesktop (Michael) >>> AA: + import existing cppunit repo into it (Markus (with Kendy)) >> >> >> With a lot of help by kendy done. Repository is now at >> http://cgit.freedesktop.org/libreoffice/cppunit. I also tagged several >> of the last releases so that you get them easily if needed. >> >> I added some of our own patches and will now have a look how to >> integrate the needed functions. Talk to me if you think that we are >> missing a cppunit feature for testing Libreoffice. The point I want to >> implement for our internal tests is a setUp/tearDown method per >> Fixture/Suite/TestClass ( extremelly important for all tests based on >> BootstrapFixture[Base]) > > > So, what is our general plan here? Is the below accurate? > > 1 Add new code to freedesktop.org/libreoffice/cppunit. Yes, I plan to add a setUpFixture/tearDownFixture that makes it possible for us to correctly start and terminate our BootStrapFixture based tests. > > 2 Make a cppunit-1.13.0 release from there (last release from its old > sourceforge home is 1.12.1). Yes. I have adapted the relevant entries in cppunit already and think that after adding this little feature and upstreaming our own patches we can think about tagging 1.13 > > 3 Make LO pull external cppunit-1.13.0 tgz from > freedesktop.org/libreoffice/cppunit (instead of cppunit-1.12.1 tgz backed up > at http://dev-www.libreoffice.org/src), adapt configure.in to require > cppunit 1.13.0 (instead of 1.12.0). Sounds like a good idea. > > 3.1 Adpate LO unit tests to make use of new cppunit features. See Point 1. I hope that this allows us to terminate LibO in our tests and find the tearDown errors we sometimes see in JUnit test also in the Cppunit tests. Since these tests are executed more often we may find some of these problems earlier and make in the same step our java based tests more reliable. > > 3.2 Tell people building LO --with-system-cppunit (incl. distro packagers) > that they need to upgrade their system's cppunit from the old sourceforge to > the new freedesktop or use --without-system-cppunit. > > 3.3 Convince distro packagers to switch from the old sourceforge to the new > freedesktop. I will write a mail to the debian packager and I think David did it for Fedora. At least the debian guys did not use plain Cppunit-1.12 but backported several of the fixes that went in after 1.12 into their package. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
On Wed, 2012-02-01 at 11:28 +0100, Stephan Bergmann wrote: > So, what is our general plan here? Is the below accurate? I guess that's what I had assumed. > 3.2 Tell people building LO --with-system-cppunit (incl. distro > packagers) that they need to upgrade their system's cppunit from the old > sourceforge to the new freedesktop or use --without-system-cppunit. I imagine it is Debian & BSD, that uses --with-system-cppunit and Markus was tackling the former. > 3.3 Convince distro packagers to switch from the old sourceforge to the > new freedesktop. It's prolly worth pinging Norbert's new distributors list as/when we have got a new release packaged, and prior to 3.6. All the best, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
On 01/27/2012 04:44 PM, Markus Mohrhard wrote: * unit test framework issues (Markus) + we are missing an important feature + cppunit development appears dead/stalled for 2+ yrs + but we support system-cppunit + can we not just declare ourselves the new up-stream for cppunit (Lionel) + requiring an internal cppunit not a big deal ? (Norbert) + always internal one for dbgutil anyway (Markus) + three options: (Stephan) 1. always use internal / patched version 2. there is a cppunit2 in Launchpad + is it compatible ? or even more active ? 3. re-evaluate whether we need cppunit, or something else: google stuff eg. 'testing framework' + looked into cppunit2 (Markus) + stopped development at same time ~2009 + project dead too. + prefer our own version, or switch to new framework for integration tests (Markus) AA: + create new cppunit repository at freedesktop (Michael) AA: + import existing cppunit repo into it (Markus (with Kendy)) With a lot of help by kendy done. Repository is now at http://cgit.freedesktop.org/libreoffice/cppunit. I also tagged several of the last releases so that you get them easily if needed. I added some of our own patches and will now have a look how to integrate the needed functions. Talk to me if you think that we are missing a cppunit feature for testing Libreoffice. The point I want to implement for our internal tests is a setUp/tearDown method per Fixture/Suite/TestClass ( extremelly important for all tests based on BootstrapFixture[Base]) So, what is our general plan here? Is the below accurate? 1 Add new code to freedesktop.org/libreoffice/cppunit. 2 Make a cppunit-1.13.0 release from there (last release from its old sourceforge home is 1.12.1). 3 Make LO pull external cppunit-1.13.0 tgz from freedesktop.org/libreoffice/cppunit (instead of cppunit-1.12.1 tgz backed up at http://dev-www.libreoffice.org/src), adapt configure.in to require cppunit 1.13.0 (instead of 1.12.0). 3.1 Adpate LO unit tests to make use of new cppunit features. 3.2 Tell people building LO --with-system-cppunit (incl. distro packagers) that they need to upgrade their system's cppunit from the old sourceforge to the new freedesktop or use --without-system-cppunit. 3.3 Convince distro packagers to switch from the old sourceforge to the new freedesktop. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
On Fri, Jan 27, 2012 at 04:44:58PM +0100, Markus Mohrhard wrote: > Hey, > > > > > * unit test framework issues (Markus) > > + we are missing an important feature > > + cppunit development appears dead/stalled for 2+ yrs > > + but we support system-cppunit > > + can we not just declare ourselves the new up-stream > > for cppunit (Lionel) > > + requiring an internal cppunit not a big deal ? (Norbert) > > + always internal one for dbgutil anyway (Markus) > > + three options: (Stephan) > > 1. always use internal / patched version > > 2. there is a cppunit2 in Launchpad > > + is it compatible ? or even more active ? > > 3. re-evaluate whether we need cppunit, or something > > else: google stuff eg. 'testing framework' > > + looked into cppunit2 (Markus) > > + stopped development at same time ~2009 > > + project dead too. > > + prefer our own version, or switch to new framework > > for integration tests (Markus) > > > AA: + create new cppunit repository at freedesktop (Michael) > > done, thanks Michael > > > AA: + import existing cppunit repo into it (Markus (with Kendy)) > > With a lot of help by kendy done. Repository is now at > http://cgit.freedesktop.org/libreoffice/cppunit. I also tagged several > of the last releases so that you get them easily if needed. Hi, I created a wiki page for cppunit at http://www.freedesktop.org/wiki/Software/cppunit . I am also going to notify the Fedora maintainer(s) of cppunit that the project is alive again :) D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
On 27/01/12 16:44, Markus Mohrhard wrote: > Hey, > >> >> * unit test framework issues (Markus) >>+ we are missing an important feature >>+ cppunit development appears dead/stalled for 2+ yrs >>+ but we support system-cppunit >>+ can we not just declare ourselves the new up-stream >> for cppunit (Lionel) >>+ requiring an internal cppunit not a big deal ? (Norbert) >>+ always internal one for dbgutil anyway (Markus) >>+ three options: (Stephan) >>1. always use internal / patched version >>2. there is a cppunit2 in Launchpad >>+ is it compatible ? or even more active ? >>3. re-evaluate whether we need cppunit, or something >> else: google stuff eg. 'testing framework' >>+ looked into cppunit2 (Markus) >>+ stopped development at same time ~2009 >>+ project dead too. >>+ prefer our own version, or switch to new framework >> for integration tests (Markus) > >> AA: + create new cppunit repository at freedesktop (Michael) > > done, thanks Michael > >> AA: + import existing cppunit repo into it (Markus (with Kendy)) > > With a lot of help by kendy done. Repository is now at > http://cgit.freedesktop.org/libreoffice/cppunit. I also tagged several > of the last releases so that you get them easily if needed. sounds good; i wonder, is there a mailing list or something over at the old sourceforge project? maybe it would be a good idea to let people know that we are maintaining this thing now... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
Hey, > > * unit test framework issues (Markus) > + we are missing an important feature > + cppunit development appears dead/stalled for 2+ yrs > + but we support system-cppunit > + can we not just declare ourselves the new up-stream > for cppunit (Lionel) > + requiring an internal cppunit not a big deal ? (Norbert) > + always internal one for dbgutil anyway (Markus) > + three options: (Stephan) > 1. always use internal / patched version > 2. there is a cppunit2 in Launchpad > + is it compatible ? or even more active ? > 3. re-evaluate whether we need cppunit, or something > else: google stuff eg. 'testing framework' > + looked into cppunit2 (Markus) > + stopped development at same time ~2009 > + project dead too. > + prefer our own version, or switch to new framework > for integration tests (Markus) > AA: + create new cppunit repository at freedesktop (Michael) done, thanks Michael > AA: + import existing cppunit repo into it (Markus (with Kendy)) With a lot of help by kendy done. Repository is now at http://cgit.freedesktop.org/libreoffice/cppunit. I also tagged several of the last releases so that you get them easily if needed. I added some of our own patches and will now have a look how to integrate the needed functions. Talk to me if you think that we are missing a cppunit feature for testing Libreoffice. The point I want to implement for our internal tests is a setUp/tearDown method per Fixture/Suite/TestClass ( extremelly important for all tests based on BootstrapFixture[Base]) Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
2012/1/26 Michael Meeks : > * Indian localisation issuse / patch (Caolan) > + happy with the patches, Windows specific issue > + need another review for -3-5-0 > + no underlying bug lurking here. > AA: + re-test under Windows and push to -3-5-0 (Andras) Done. Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
Hi , Michael Meeks wrote (26-01-12 18:30) + 3.5.0 status + [...] + no real blockers. + still plenty of annoying bugs + need to release-note lots of them. + but fixing rate is going well - thanks a lot ! * QA update (Rainer) + most annoying bugs + lots of nominations, without a dep. entry Sadly I did not yet look into the results of the past weekend, the second BHS, and the issues submitted then/around these dates. Rainer / *: did you/others have a change to have a look, so not to miss potential big probs? Regards, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
Ivan Timofeev wrote: > So, I either have to reassign the bug to Thorsten or have to ask how > to make the patch better. :) > Hah, wonderful - let me get to that tomorrow first thing! :) Cheers, -- Thorsten pgpCylVxonopw.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
Hi Ivan, On Thu, 2012-01-19 at 21:59 +0400, Ivan Timofeev wrote: > > + hack up the Help->File bug menu item (Thorsten) > We have the bug for this: > https://bugs.freedesktop.org/show_bug.cgi?id=35855 > and Rainer assigned it to me and I even have a patch (of dubious quality > though :) - attaching it. Great news ! :-) Looks like you got most of this there. > So, I either have to reassign the bug to Thorsten or have to ask how to > make the patch better. :) It's fine to work on it - but perhaps Thorsten can help you out. Now I see it, I wonder whether this new menu item will break the translation freeze ... > Thorsten, are you working on this already? Luckily, I think not yet :-) Thanks, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
19.01.2012 19:44, Michael Meeks пишет: * Pending Action Items + hack up the Help->File bug menu item (Thorsten) Oh, I've just noticed this ^^^ We have the bug for this: https://bugs.freedesktop.org/show_bug.cgi?id=35855 and Rainer assigned it to me and I even have a patch (of dubious quality though :) - attaching it. So, I either have to reassign the bug to Thorsten or have to ask how to make the patch better. :) Thorsten, are you working on this already? Best Regards, Ivan >From 186a015831027d5a8c77a0110b49b3e4614ac38d Mon Sep 17 00:00:00 2001 From: Ivan Timofeev Date: Wed, 18 Jan 2012 22:47:58 +0400 Subject: [PATCH] add the "Send Feedback..." help menu item --- basctl/uiconfig/basicide/menubar/menubar.xml |3 +- chart2/uiconfig/menubar/menubar.xml|3 +- dbaccess/uiconfig/dbapp/menubar/menubar.xml|3 +- dbaccess/uiconfig/dbquery/menubar/menubar.xml |3 +- dbaccess/uiconfig/dbrelation/menubar/menubar.xml |3 +- dbaccess/uiconfig/dbtable/menubar/menubar.xml |3 +- dbaccess/uiconfig/dbtdata/menubar/menubar.xml |3 +- .../uiconfig/sbibliography/menubar/menubar.xml |3 +- framework/uiconfig/startmodule/menubar/menubar.xml |3 +- .../org/openoffice/Office/UI/GenericCommands.xcu |5 reportdesign/uiconfig/dbreport/menubar/menubar.xml |3 +- sc/uiconfig/scalc/menubar/menubar.xml |3 +- sd/uiconfig/sdraw/menubar/menubar.xml |3 +- sd/uiconfig/simpress/menubar/menubar.xml |3 +- sfx2/inc/sfx2/sfxsids.hrc |1 + sfx2/sdi/appslots.sdi |4 +++ sfx2/sdi/sfx.sdi | 25 sfx2/source/appl/appserv.cxx | 16 starmath/uiconfig/smath/menubar/menubar.xml|3 +- sw/uiconfig/sglobal/menubar/menubar.xml|3 +- sw/uiconfig/sweb/menubar/menubar.xml |3 +- sw/uiconfig/swform/menubar/menubar.xml |3 +- sw/uiconfig/swreport/menubar/menubar.xml |3 +- sw/uiconfig/swriter/menubar/menubar.xml|3 +- sw/uiconfig/swxform/menubar/menubar.xml|3 +- 25 files changed, 91 insertions(+), 20 deletions(-) diff --git a/basctl/uiconfig/basicide/menubar/menubar.xml b/basctl/uiconfig/basicide/menubar/menubar.xml index 15d4fcd..0d7ecd7 100644 --- a/basctl/uiconfig/basicide/menubar/menubar.xml +++ b/basctl/uiconfig/basicide/menubar/menubar.xml @@ -83,8 +83,9 @@ - + + diff --git a/chart2/uiconfig/menubar/menubar.xml b/chart2/uiconfig/menubar/menubar.xml index 3c50167..a52dff8 100644 --- a/chart2/uiconfig/menubar/menubar.xml +++ b/chart2/uiconfig/menubar/menubar.xml @@ -147,8 +147,9 @@ - + + diff --git a/dbaccess/uiconfig/dbapp/menubar/menubar.xml b/dbaccess/uiconfig/dbapp/menubar/menubar.xml index a76fda5..0367d7e 100644 --- a/dbaccess/uiconfig/dbapp/menubar/menubar.xml +++ b/dbaccess/uiconfig/dbapp/menubar/menubar.xml @@ -133,8 +133,9 @@ - + + diff --git a/dbaccess/uiconfig/dbquery/menubar/menubar.xml b/dbaccess/uiconfig/dbquery/menubar/menubar.xml index 2d6ec8d..e041079 100644 --- a/dbaccess/uiconfig/dbquery/menubar/menubar.xml +++ b/dbaccess/uiconfig/dbquery/menubar/menubar.xml @@ -74,8 +74,9 @@ - + + diff --git a/dbaccess/uiconfig/dbrelation/menubar/menubar.xml b/dbaccess/uiconfig/dbrelation/menubar/menubar.xml index b7460a4..7dc66d0 100644 --- a/dbaccess/uiconfig/dbrelation/menubar/menubar.xml +++ b/dbaccess/uiconfig/dbrelation/menubar/menubar.xml @@ -57,8 +57,9 @@ - + + diff --git a/dbaccess/uiconfig/dbtable/menubar/menubar.xml b/dbaccess/uiconfig/dbtable/menubar/menubar.xml index ede5eed..439a735 100644 --- a/dbaccess/uiconfig/dbtable/menubar/menubar.xml +++ b/dbaccess/uiconfig/dbtable/menubar/menubar.xml @@ -58,8 +58,9 @@ - + + diff --git a/dbaccess/uiconfig/dbtdata/menubar/menubar.xml b/dbaccess/uiconfig/dbtdata/menubar/menubar.xml index 79fe68a..254f3b7 100644 --- a/dbaccess/uiconfig/dbtdata/menubar/menubar.xml +++ b/dbaccess/uiconfig/dbtdata/menubar/menubar.xml @@ -66,8 +66,9 @@ - +
Re: [Libreoffice] minutes of ESC call ...
On Thu, 2012-01-19 at 15:44 +, Michael Meeks wrote: > * Present: > + Andras, Norbert, Tor, Michael, Thorsten, Eike, > Mitch, David, Rainer, Stephan, Fridrich, Bjoern, > Michael S, Lionel Just FYI (it doesn't matter much but) I was there too. But I didn't utter my name loud enough. :-P Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
Hi *, On Thu, Jan 12, 2012 at 5:23 PM, Michael Meeks wrote: > * QA update (Rainer) > + Windows 8 problem > + running under Virtualbox, can be reproduced > + Bugzilla updates sorted out with Thorsten > + status of permanent re-direction link for assistant ? > + admins need to be told what link they want > + create link in a couple of minutes, > ver+os+ as parameters to allow re-direction of > old versions. > AA: + create http://hub.libreoffice.org/file-a-bug/ (Christian) Done - although the "file-a-bug" more or less was meant as placeholder for whatever term will be used. So if you want another one, let me know. The idea of hub.libreoffice.org/?param1=value1[¶mX=valueX] is to have "never changing" URLs to be used in the program as well as in printed stuff. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
Michael Meeks píše v Čt 12. 01. 2012 v 16:23 +: > Hard English string & UI freeze - in effect now > > + After Monday/Tuesday's RC1 tag need a 2nd review It means to ask for one review/approval on the libreoffice@lists.freedesktop.org mailing list before cherry-pikcing from master. This is the usual rule for the libreoffice-A-X branches as described at http://wiki.documentfoundation.org/Development/Branches > From Monday 16th - one extra pair of eyes needed per commit > > + the future: > + 2x extra patch reviewers starts at RC2 We will create the libreoffice-3-5-0 from the tag for 3.5.0-rc2 (about Jan 24). So, these is the usual rule for libreoffice-A-X-Y branches as described at http://wiki.documentfoundation.org/Development/Branches > + 3x extra patch reviewers starts at RC3 rc3 should be final, so there won't be this extra level of review. I am sorry if I explained it a confusing way on the TSC call. I hope that the above comments make it more clear :-) Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
On Wed, 2012-01-11 at 16:47 +0100, Jesús Corrius wrote: > > I confirm the bug with LibO 3.5 beta 2. > > Windows 8 works perfectly well in VirtualBox :) > > OK. It's a duplicate of this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=43989 Be great to get a trace and work out what exit code is popping out from there, and why :-) [ so we're not re-starting correctly ]. Thanks, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
2012/1/11 Jesús Corrius : >> + Windows 8 - public beta for Feburary >> + Win 8 doesn't install in VMWare >> - until it does debugging is hard. >> + crash-on-load bug #43648 - fun. >> + Jesus reports it working well though ... > > I confirm the bug with LibO 3.5 beta 2. > Windows 8 works perfectly well in VirtualBox :) OK. It's a duplicate of this bug: https://bugs.freedesktop.org/show_bug.cgi?id=43989 Sorry for the noise :) -- Jesús Corrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
> + Windows 8 - public beta for Feburary > + Win 8 doesn't install in VMWare > - until it does debugging is hard. > + crash-on-load bug #43648 - fun. > + Jesus reports it working well though ... I confirm the bug with LibO 3.5 beta 2. Windows 8 works perfectly well in VirtualBox :) -- Jesús Corrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
Michael Meeks wrote: > AA: + qa list incomplete, or updating slowly on gmane (Thorsten to > poke Florian) > Seems setup is no different than for the other lists, additionally, for the last handful of days, I see no missing mails. Could you point out concrete examples? Cheers, -- Thorsten pgpuydIhsYjdx.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
Michael Meeks wrote: > + cleanup old test build server directories (Thorsten) > Done. > + Excel (originally Lotus) leap-year bug #44453 > + we simply don't do the broken version > + known issue, affecting only 50 dates. > AA: + wontfix the bug in pleasant way (Thorsten) > Even better, fix some easy low-hanging fruits around xlsx -> Kohei is handling that. Cheers, -- Thorsten pgp1z70uSjuGo.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
On Fri, 2012-01-06 at 11:28 +, Caolán McNamara wrote: > On Thu, 2012-01-05 at 17:43 +, Michael Meeks wrote: > > + upgrade the internal cairo to latest stable to fix theme crasher > > (Fridrich) > > + side-effect: > > https://bugs.freedesktop.org/show_bug.cgi?id=44219 > > + in-progress (Caolan, Michael) > > done. Patch looks lovely to me :-) thanks for that - it's in 3.5 already I see (which is great). Thanks, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of ESC call ...
On Thu, 2012-01-05 at 17:43 +, Michael Meeks wrote: > + upgrade the internal cairo to latest stable to fix theme crasher > (Fridrich) > + side-effect: > https://bugs.freedesktop.org/show_bug.cgi?id=44219 > + in-progress (Caolan, Michael) done. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
