Re: [Libreoffice-qa] moztrap documentation feedback
Hi Petr, Thomas, On Tue, Apr 09, 2013 at 01:17:37PM +0200, Petr Mladek wrote: And I seem to remember (from the ToDo list, I think ... ;) ) that an import of old test cases is planned. What is the status here? Are translations of them are imported as well? AFAIK, Yi Fan already ported all useful test cases. I think that he ignored some trivial tests that did not make much sense. But I might be wrong. Yes, the status is done :) We have migrated old cases from Litmus and got them updated to Moztrap with merging duplicated steps or cases as well as wording revising. 2. How do I get my translated test cases in a test run? A short test during my translation shows me, that they were not in there ... :( Or does someone have to prove them first and then they get active? I am afraid that this is related to the branches. If you modify the text in the branch 0 it is not automatically updated in other branches. I am not sure if there is a way to synchronize this. Yi Fan? Usually when we have a newly added test case translation in version 0, it will take effect as a new version is created, which is copied from test case version 0. By the fact a test cases in a test run is bound to a specific version, to make the translation taking effect for an existed test run, we need to update the test case content for a speific version more than for version 0 only. That is to say, switch to the right test case version then paste the newly added translation from version 0 :) Best wishes, Yifan -- Yifan Jiang Libreoffice / SUSE Contact: yifan - irc.freenode.net/libreoffice = http://www.libreoffice.org/ http://www.documentfoundation.org/ ___ 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] Removing LibO 3.3 from Versions dropdown in Bugzilla
Rainer Bielefeld schrieb: I am thinking about a Version picker cleanup by removing most 3.3. Versions. Hi, unfortunately that only will bring progress for the Bugzilla Version Dropdowns, but not for the BSA Vrsion selectors before a fix for Bug 55460 - BUGZILLAASSISTANT: Exclude inactive versions from version selector https://bugs.freedesktop.org/show_bug.cgi?id=55460 But inactive Versions do not cause Problems for BSA bug submissions for those versions, so that BSA problem does not hinder. 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/
[Libreoffice-qa] Master daily builds for Windows are broken
The last successful build is from April 8th at 5 AM. Dev support needed here :) Thanks! -- View this message in context: http://nabble.documentfoundation.org/Master-daily-builds-for-Windows-are-broken-tp4048968.html Sent from the QA mailing list archive at Nabble.com. ___ 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] Lifecycle of builds?
Hi Robinson, On Tue, 2013-04-09 at 19:52 -0400, Robinson Tryon wrote: As Pedro mentioned, and as far as I understand it, our next step is to pick an EOL date for each of our builds and then go update the wiki pages. I'd be happy to help update the ReleaseNotes wiki pages, or to ping pmladek and hand that task over to him. Well - I guess Petr is the best guy to hack that page :-) Mmeeks suggested in this thread that 3.5.x should be considered EOL at this point. As the last release (3.5.7) shipped about 6 months ago, I suggest 6 months as the standard lifetime for our stable, shipped builds. Seems reasonable - 3.6.x will last a bit longer because of the jump to 4.0 I think; currently planned at 9 months. Would changing 'Old Releases' to End of Life Releases in: https://wiki.documentfoundation.org/ReleasePlan do it ? with a bit of text saying: A release normally has a lifetime of around six months, however if you want longer term support for a release, you're encouraged to engaged any certified L3 provider to provide you with support. or something. Why add that marketing blurb ? I don't want people to think the code is un-supportable after 6 months; in fact we (SUSE) continue to support branches based on old releases for our customers, and the lifetime can play into product choice decisions. How does that sound ? Thanks for following this up ! 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] Lifecycle of builds?
Michael Meeks-2 wrote Seems reasonable - 3.6.x will last a bit longer because of the jump to 4.0 I think; currently planned at 9 months. So End of Life occurs 6 months after the official release date of the final release for each branch (usually final version is x.x.7) and occurs after 9 months for the final release before a major version change (e.g from 3.x to 4.x)? Can it be assumed that the official release date is the date when it is announced on the official blog? http://blog.documentfoundation.org/ Therefore EOL for branch 3.5 is on April 18th (http://blog.documentfoundation.org/2012/10/18/the-document-foundation-announces-libreoffice-3-5-7/), right? EOL for branch 3.6 should be removed from the image since release x.x.7 isn't out yet Does this also mean that 3.4 versions can already be removed from the bugzilla Version picker? And 3.5 versions after the 18th of this month? Cheers, Pedro -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Lifecycle-of-builds-tp4048583p4048978.html Sent from the QA mailing list archive at Nabble.com. ___ 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] [ANN] LibreOffice 3.6.6 RC2 available
On Tue, Apr 09, 2013 at 09:36:20PM -0400, Dan Lewis wrote: Next question. Has there been a change in where LibreOffice is located? I installed LibreOffice 3.6.6.2 using the commands you gave me above. This installed it in /usr/lib/libreoffice rather than /opt/libreoffice3.6. As a result I have 3.5.6.2 installed as well as 3.6.6.2. /usr/lib/libreoffice is the properly packaged build from Ubuntu/Debian packaging. /opt/libreoffice is the TDF builds which are backwards compatible with ancient distros. Dont use them, if you can get properly packaged builds IMHO. 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] Lifecycle of builds?
Pedro wrote: Does this also mean that 3.4 versions can already be removed from the bugzilla Version picker? And 3.5 versions after the 18th of this month? Hi Pedro, no, we can't. Version info in BZ should show where the bug appeared (or at least has been observed the first time), also see https://wiki.documentfoundation.org/BugReport_Details#Version. That has nothing to do with our maintenance for a Version branch. Please also see [Libreoffice-qa] Removing LibO 3.3 from Versions dropdown in Bugzilla, where I demonstrated some criteria for versions removal. I think End of 2013 we can think about something similar for 3.4. 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] Lifecycle of builds?
Hi Rainer Rainer Bielefeld-2 wrote Version info in BZ should show where the bug appeared (or at least has been observed the first time) The point here is that if a version is past the EOL and nobody will fix bugs in that branch, there is no point in reporting bugs first observed in 3.4 or 3.5 (otherwise you should NOT remove 3.3 from the list either) Rainer Bielefeld-2 wrote I think End of 2013 we can think about something similar for 3.4. Isn't that up to the BOD to decide? If the EOL was after 6 months why End of 2013? Cheers, Pedro -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Lifecycle-of-builds-tp4048583p4049029.html Sent from the QA mailing list archive at Nabble.com. ___ 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] Lifecycle of builds?
Pedro schrieb: The point here is that if a version is past the EOL and nobody will fix bugs in that branch, there is no point in reporting bugs first observed in 3.4 or 3.5 (otherwise you should NOT remove 3.3 from the list either) Hi Pedro, you are completely wrong, I doubt that you read the linked texts. Isn't that up to the BOD to decide? If the EOL was after 6 months why End of 2013? I do not see to what you refer, my comment was concerning removal of 3.4 versions from BZ Version picker (the same way I will do for 3.3 this week), what is completely out of BODs interest. 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] [ANN] LibreOffice 3.6.6 RC2 available
On 04/10/2013 07:55 AM, Bjoern Michaelsen wrote: On Tue, Apr 09, 2013 at 09:36:20PM -0400, Dan Lewis wrote: Next question. Has there been a change in where LibreOffice is located? I installed LibreOffice 3.6.6.2 using the commands you gave me above. This installed it in /usr/lib/libreoffice rather than /opt/libreoffice3.6. As a result I have 3.5.6.2 installed as well as 3.6.6.2. /usr/lib/libreoffice is the properly packaged build from Ubuntu/Debian packaging. /opt/libreoffice is the TDF builds which are backwards compatible with ancient distros. Dont use them, if you can get properly packaged builds IMHO. Best, Bjoern Sorry, I meant 3.6.5.2 *not* 3.5.6.2. But I am still a bit confused about what is available at the PPA. I thought I was getting the build from TDF rather than from Ubuntu/Debian. Yet, when I opened Synaptic and looked at what I had installed, it indicated that I had gotten the build from Ubuntu/Debian, namely 1:3.6.6~RC2-0ubuntu~precise~ppa2. That download was approximately 97 MB. The TDF built download (3.6.6.2) is 179 MB. So, what are the difference between these two builds? Since I am involved in TDF documentation, I probably need to continue to download the builds from the TDF website. Thanks for sending me a copy of what you posted to QA. It was very thoughtful of you. I am subscribed to the QA mailing list so this will not be necessary. (I also am subscribed to the DEV, documentation, and user mailing lists (I'm not sure how important this is to others. --Dan ___ 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] Lifecycle of builds?
On Wed, Apr 10, 2013 at 8:02 AM, Rainer Bielefeld libreoff...@bielefeldundbuss.de wrote: Pedro wrote: Does this also mean that 3.4 versions can already be removed from the bugzilla Version picker? And 3.5 versions after the 18th of this month? Hi Pedro, no, we can't. Version info in BZ should show where the bug appeared (or at least has been observed the first time) It sounds like we're got a balancing act: Provide enough versions in the picker that one has some granularity, but not clog-up the picker with tons of old version numbers, including beta builds, etc.. https://wiki.documentfoundation.org/BugReport_Details#Version. That has nothing to do with our maintenance for a Version branch. Not sure what's relevant on that page... Please also see [Libreoffice-qa] Removing LibO 3.3 from Versions dropdown in Bugzilla, where I demonstrated some criteria for versions removal. Link for easy reading :-) http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.qa/3962 Rainer wrote: So I believe we should mark the not-release-3.3 as inactive, what means they will stay for the bugs where they are used, but can not be used for new bug reports (except by the LibO Bugzilla Administrators) because they will no longer be shown in the Versions selector. To riff off of your suggestion, perhaps we can do our cleanup in stages: 1) When we EOL a stable release such as 3.5.5, we remove (i.e. mark as inactive) all of the not-release-3.5.5.x versions from the bugtracker. This will still allow us to report bugs against the stable release, and if someone wants to test against a beta build and insert that information into the bug report (or even into the Summary), then that possibility remains. 2) When we EOL a release series such as 3.5, we *could* do more cleanup, but there still may be end users running those stable builds. As Michael pointed out, we still have companies interested in maintenance on those older versions. Ubuntu 12.04 still has a 3.5 build, and I'm not sure if/when that will be upgraded. Realistically, I think we can punt on this piece of the puzzle until another day. Thoughts? Cheers, --R ___ 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] Lifecycle of builds?
Hi Rainer Rainer Bielefeld-2 wrote you are completely wrong, I doubt that you read the linked texts. I did read the texts. Have you considered the hypothesis that YOU might be wrong? You are confusing QA work with a reporter's work. Someone who submits a bug is going to report the version where he found the bug. He is not going to install previous versions to check back. That is QA work. So maybe there should be two separate fields: one for the reporter to indicate in which version he observed the bug and another field for the QA (or the reporter if he is willing to do that) to report in which version it was first observed (if it is a new bug, i.e. not a regression then both fields match) In the QA field ALL versions including the 3.3 branch should show up. Maybe in the user field only actively developed versions should show up? If bugs are not going to be fixed in EOL branches it makes more sense to advise the user to update to a live branch and then to report the bug if it still exists... Regards, Pedro -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Lifecycle-of-builds-tp4048583p4049059.html Sent from the QA mailing list archive at Nabble.com. ___ 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] Lifecycle of builds?
Michael Meeks píše v St 10. 04. 2013 v 10:25 +0100: Hi Robinson, On Tue, 2013-04-09 at 19:52 -0400, Robinson Tryon wrote: As Pedro mentioned, and as far as I understand it, our next step is to pick an EOL date for each of our builds and then go update the wiki pages. I'd be happy to help update the ReleaseNotes wiki pages, or to ping pmladek and hand that task over to him. Well - I guess Petr is the best guy to hack that page :-) Mmeeks suggested in this thread that 3.5.x should be considered EOL at this point. As the last release (3.5.7) shipped about 6 months ago, I suggest 6 months as the standard lifetime for our stable, shipped builds. Seems reasonable - 3.6.x will last a bit longer because of the jump to 4.0 I think; currently planned at 9 months. I see that you both use a bit different logic, so we need to decide how we count the 6 and 9 months. I understand it the following way: + the release is defined by the minor version release, e.g. 3.6 or 4.0 + regular and extra bugfix releases are provided during the life time + the life starts with the .0 release + the life ends when we are not willing to provide any new bugfix release I think that it would be fair to make it live at least 4 weeks after the last scheduled bugfix release. By other words, we should provide extra bugfix release if we add serious regression into the last bugfix release. If we do it this way, the numbers would look like: version start endlength + 3.6 Aug 8, 2012 Aug 14, 2013 12 months + 4.0 Feb 6, 2013 Nov 20, 2013 9 months + 4.1 Jul 24, 2013May 28, 2013 9 months It is basically what Michael mentioned because the .0 release is for early adopters. The release is stable around .3 bugfix relase which is 3 months after the .0 release. Would changing 'Old Releases' to End of Life Releases in: https://wiki.documentfoundation.org/ReleasePlan Done, including the marketing hint, see https://wiki.documentfoundation.org/ReleasePlan#End_of_Life_Releases I wonder if there is a list of certified developers somewhere. I have found only the description at https://wiki.documentfoundation.org/TDFCertification ___ 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] Lifecycle of builds?
Robinson Tryon wrote Oh, certainly. Perhaps Pedro meant that we shouldn't remove *all* of the 3.3 builds from the picker, for this very reason. Rainer described this as not-release-3.3 [builds]. I think we're mostly in agreement here :-) Yes, exactly. I just read the title of Rainer other thread. I wrongly assumed he meant removing ALL 3.3 versions except for version LibO 3.3.0 Beta2. Apologies on the confusion. See my previous mail with suggestion on having two separate fields: one for the version reported (where the user observed it) and one for the first occurrence (determined by QA) Regards, Pedro -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Lifecycle-of-builds-tp4048583p4049069.html Sent from the QA mailing list archive at Nabble.com. ___ 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] Lifecycle of builds?
Robinson Tryon píše v St 10. 04. 2013 v 10:12 -0400: On Wed, Apr 10, 2013 at 8:02 AM, Rainer Bielefeld Rainer wrote: So I believe we should mark the not-release-3.3 as inactive, what means they will stay for the bugs where they are used, but can not be used for new bug reports (except by the LibO Bugzilla Administrators) because they will no longer be shown in the Versions selector. Nice feature To riff off of your suggestion, perhaps we can do our cleanup in stages: Makes sense. 1) When we EOL a stable release such as 3.5.5, we remove (i.e. mark as inactive) all of the not-release-3.5.5.x versions from the bugtracker. I think that it is hard to define life time for a bugfix release. It is basically obsoleted by the next bugfix release for the given minor version. If we accept this, it would mean to remove betas and rcs for X.Y.Z when X.Y.Z+1 bugfix release is released. For example, remove 4.0.2 RCs when 4.0.3 is released. It could work. The logic here is that people, who install RCs from prerelease, usually install newer RCs when they are available. The RCs granularity gets outdated with next release because most people do not have them installed. If anyone wants to find when it exactly got broken, they probably use bibisect which uses another identification. Maybe we could wait one more bugfix release, just for sure. See below. 2) When we EOL a release series such as 3.5, we *could* do more cleanup, but there still may be end users running those stable builds. As Michael pointed out, we still have companies interested in maintenance on those older versions. Ubuntu 12.04 still has a 3.5 build, and I'm not sure if/when that will be upgraded. Realistically, I think we can punt on this piece of the puzzle until another day. I would probably leave it a bit longer. It seems that people still use different 3.4.x bugfix releases. I did a query for bugs reported this year: + 64 bugs are marked against the version 3.4.* + 1 is against 3.4.*RC.* (fdo#53725) + 2 are against 3.4.6 release (last one) + 61 are against other 3.4.x releases Best Regards, Petr ___ 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] Lifecycle of builds?
On Wed, Apr 10, 2013 at 10:33 AM, Petr Mladek pmla...@suse.cz wrote: I see that you both use a bit different logic, so we need to decide how we count the 6 and 9 months. I understand it the following way: + the release is defined by the minor version release, e.g. 3.6 or 4.0 + regular and extra bugfix releases are provided during the life time + the life starts with the .0 release + the life ends when we are not willing to provide any new bugfix release So would we provide an EOL date for each point release in a series, or just a single EOL date for all of our 3.6.x released builds? Granularity is nice, but one EOL for the entire release series might be easier to manage. I'd often thought of each 3.5.x build as a separate release, but as you describe it, it's mostly just a maintenance schedule. I think that it would be fair to make it live at least 4 weeks after the last scheduled bugfix release. By other words, we should provide extra bugfix release if we add serious regression into the last bugfix release. 4 weeks of support for a regular build seems pretty short, but when you describe it as a bugfix release, it makes a lot more sense in my mind. Perhaps we could add some language on the ReleasePlan page to help telegraph the impending end of the series? Maybe in the tables of releases: 3.6.0 ... 3.6.6 bugfix 3.6.7 bugfix Is there a better/shorter label we could apply there? If we do it this way, the numbers would look like: version start endlength + 3.6 Aug 8, 2012 Aug 14, 2013 12 months + 4.0 Feb 6, 2013 Nov 20, 2013 9 months + 4.1 Jul 24, 2013May 28, 2013 9 months It is basically what Michael mentioned because the .0 release is for early adopters. The release is stable around .3 bugfix relase which is 3 months after the .0 release. Ah, okay, so perhaps a new column in the table: 3.6.0 - early adopters 3.6.1 - (or maybe 'unstable'? marketing would hate that..) 3.6.2 - (Better: leave it empty until we can mark it 'stable' :-) 3.6.3 - stable ... 3.6.6 - bugfix 3.6.7 - bugfix Then if we had to add an extra bugfix, we could do something like 3.6.8 - special bugfix Unlike the rest of the information in the table, the labels in this column could be added at each new release, especially as we don't know at the outset which point release we'll feel confident to mark as 'stable'. I wonder if there is a list of certified developers somewhere. I have found only the description at https://wiki.documentfoundation.org/TDFCertification https://www.documentfoundation.org/certification/developers/ I would suggest that you link to some internal page on the wiki (say TDF/certification), as it's likely that other pages will want to mention the certification program or the currently-certified developers. --R ___ 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] Bug 63388: Mail Merge Email
I have filed this bug because I can not get LibreOffice to test the settings I enter into Tools Options LibreOffice Writer Main Merge. It freezes everytime. All the information I enter is copied from the Account Settings in Thunderbird. I have verified that the password I entered will open Gmail on the Google website. I use IMAP rather than POP3. Do others have this problem? Is there something special that I am not doing to cause LO to freeze when running this test? --Dan ___ 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] Bug 63388: Mail Merge Email
Le 10/04/13 17:50, Dan Lewis a écrit : Hi Dan, I have filed this bug because I can not get LibreOffice to test the settings I enter into Tools Options LibreOffice Writer Main Merge. It freezes everytime. All the information I enter is copied from the Account Settings in Thunderbird. I have verified that the password I entered will open Gmail on the Google website. I use IMAP rather than POP3. Do others have this problem? Is there something special that I am not doing to cause LO to freeze when running this test? I have this problem too, but I thought that it had already been entered as a bug. I've not found a way for the test to complete without freezing LO (and requiring force kill) thus far. Alex ___ 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] Master daily builds for Windows are broken
Actually, what I mentioned in the previous email refers to Tinderbox #6 Oddly enough, Tinderbox #16 (still named W2008R2...) hasn't failed since April 1st because it is not compiling since then :) -- View this message in context: http://nabble.documentfoundation.org/Master-daily-builds-for-Windows-are-broken-tp4048968p4049085.html Sent from the QA mailing list archive at Nabble.com. ___ 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] moztrap documentation feedback
Hello Yifan, *, On Wed, Apr 10, 2013 at 02:03:33PM +0800, Yifan Jiang wrote: On Tue, Apr 09, 2013 at 01:17:37PM +0200, Petr Mladek wrote: [import of old test cases] AFAIK, Yi Fan already ported all useful test cases. I think that he ignored some trivial tests that did not make much sense. But I might be wrong. Yes, the status is done :) We have migrated old cases from Litmus and got them updated to Moztrap with merging duplicated steps or cases as well as wording revising. O.K. Thanks for the info :) 2. How do I get my translated test cases in a test run? A short test during my translation shows me, that they were not in there ... :( Or does someone have to prove them first and then they get active? I am afraid that this is related to the branches. If you modify the text in the branch 0 it is not automatically updated in other branches. I am not sure if there is a way to synchronize this. Yi Fan? Usually when we have a newly added test case translation in version 0, it will take effect as a new version is created, which is copied from test case version 0. O.K. By the fact a test cases in a test run is bound to a specific version, to make the translation taking effect for an existed test run, we need to update the test case content for a speific version more than for version 0 only. That is to say, switch to the right test case version then paste the newly added translation from version 0 :) Sigh ... Is there no easier way? That would be nice ... ;) Have a nice evening Thomas. -- ...when fits of creativity run strong, more than one programmer or writer has been known to abandon the desktop for the more spacious floor. -- Fred Brooks, Jr. ___ 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] Consistent Time for Meetings
Hi All, So we need to set an official, every two week (or maybe 3?) time for our meetings. Mostly this has been at 1300 GMT/UTC (before 1400 GMT/UTC) on every other Friday. This time is *slightly* inconvenient for me (quite early) but if it's the easiest on everyone else I say we set it in stone, we either meet that day or we cancel the meeting (no more moving it around, I think it gives a bad message, leads to discouragement for members that were planning on joining but then time is moved, plus just is unprofessional in general). Robinson made a great point that this *does not* exclude special meetings, it just means we'll have regular scheduled meetings which can be canceled if needed. The main agenda should be taken care of on regularly scheduled meetings, special meetings should be for an individual item that needs additional discussion. So again, I'm happy to stick with 1300 UTC/GMT if it's best for everyone, if others are open to alternative times here is what I prefer. M/T/W/F - 1400 UTC/GMT (one hour later than currently set) M-F - 1900 - 2000 (start time between this period) Remember on the half hour is fine also in that range. I really am hoping to get a time that we can all usually make. If this means Friday at 1300, so be it, we'll set the time and be done with it. Please respond in the next day or two so that we can get this officially announced, and set the next agenda time. Thanks all, sorry again that I missed todays meeting. Best, Joel ___ 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/
