Re: [Libreoffice-qa] [libreoffice-accessibility] Adding Accessibility component to Bug Assistant
Rainer Bielefeld píše v Pá 31. 08. 2012 v 06:36 +0200: the advantage of an Accessibility Component would be that it can easily be selected from a pulldown, no typos or other mistakes can happen.But a problem is that an Accessibility Component would not indicate what developer might be the one who can fix the problem. So it always would be replaced during the bug triaging and fixing process. Well, I think think that most bugs will be about that accessibility does not work at all or that it does not work for some particular UI elements. I think that most bugs will affect all LO applications and will be in the shared code = the component would be fine after all. I would imagine that we get an expert interested for these bugs. So I currently think about a Bug Submission Assistant enhancement. We can add a checkbox Accessibility affected, and the Assistant will add Accessibility Interesting idea; Well, it does not solve the problem when people report bugs directly into bugzilla. a) as additional pseudo key word to the Bug Summary line. The advantage of this solution is that the key word would be very visible. or b) as additional pseudo key word to the whiteboard or will c) set Key word Accessibility to the Keyword pane (it should not be a problem to get this new key word from FDO). The advantae of this solution is that it also eases and unifies handling in Bugzilla itself, not only via BSA. And of course d) New Component Accessibility still can be discussed. My order of preference (descending): c - a - b - d Your opinion? After all, my preference is: d a b c d - is easiest for implementing and also for using by disabled users; it would work well a - is natural; people would mention this word anyway in the summary b - we use whiteboard in many other situations already c - keywords are not much used these days = non-standard solution 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] QA Easyhack prosposal
Florian Reisinger píše v Po 03. 09. 2012 v 17:47 +0200: What is the exact plan with the queries? :-) If there is a question like this: Hmm, I want to help LibreOffice, but I don't know where to start..! There is no real answer for QA, except: Have a look at bugzilla. There you have to query the bugs you want to triage and then filter the OS, so that you can test properly... TBC ... BTW: If you have any questions, feel free to ask at this list Answer like it should IMHO be: You can download a .ods file here: Link In this file, you can see bugs, which needs to be triaged. Open the table with your OS and click one of the bug numbers. The queries are auto-updated each hour. For more info, questions ect. ask here. But it didn't work due to a bug (which should be filed ASAP). I see, it makes sense. Note that Joel already created some documents, see Google Documents Bug Groups at https://wiki.documentfoundation.org/BugTriage_InProgress 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] Shift 3.7.0 or 3.7.X releases - was: ANNOUNCE: Release plan updated - two weeks between RCs
Bjoern Michaelsen píše v Čt 30. 08. 2012 v 17:41 +0200: On Thu, Aug 30, 2012 at 05:14:02PM +0200, Petr Mladek wrote: As mentioned, the 3.7.0 release and 3.7.1-rc1 are planed for the same week now. It is bad because there is no time to proceed feedback from 3.7.0 users. Comparing: https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule http://wiki.documentfoundation.org/ReleasePlan/3.7 I find currently: - the 3.7.0 is already too late for a Alpha1/FeatureFreeze Well, the LO feature freeze is already for beta1 in December. The hard code freeze is three weeks before the .0 release. I guess that 3.6.0-rc2 would be fine for Ubuntu alpha1. - the 3.7.1 is already currently is ok for the BetaFreeze (LibreOffice is seeded) - the 3.7.2 release is fitting in just before Final Freeze I see. OK, we can't move it later. - the 3.7.3 release is already a SRU (stable release update) Possible solutions: 1. Make 3.7.0 two weeks earlier. I am not happy to change this so close to the feature freeze. It might be possible. Let's discuss it on ESC call this week. 2. Make 3.7.X bugfix releases 1 or 2 weeks later. It might cause troubles for Ubuntu, Fedora, and other distros who planed to use .3 bugfix release in their distro releases. Well, they might use 3.7.3-rc1 or 3.7.2. They should be pretty good as well. The number of weeks for bugfixing stays the same. 3.x.3 is already too late for us currently -- however, pushing back two weeks would make 3.7.2 miss final freeze. In that case I would have to seriously consider to not ship that series at all -- shipping with a 3.7.1 is very likely too early. This is no way. We do not want to break your release. 3. Remove 3.7.0-rc3 or some beta. It would mean to do the hard code freeze 1 or two weeks earlier = less time for testing and fixing Personally, that sounds like the best option for me for 3.7. I am not much happy with it because it could cause worse quality of .0 release. 4. Do 3.7.0-RCs every week (use the original schedule). There is not enough time for feedback = demotivating for QA. After all, this is still good solution. We released, 3.5 and 3.6 this way and it somehow worked. The .0 release is always hectic and we get many fixes every week, so the two weeks delay between rc2 and rc3 would be too long. If ESC rejects moving the whole release two weeks earlier, I would go with tho 4th solution and do builds every week for 3.7.0 and 3.7.1 releases. Of course, I would shift the whole release in the future. Thanks for feedback. 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] Regression test (Moztrap) test case localization temporary solution.
Hi Petr, all, On 03/09/2012 17:34, Petr Mladek wrote: [...] So the feedback from our team is the 2nd presentation that is preferred over the others, it seems to be more readable for all of them. May be we can go for the first presentation until we get more languages but do not forget about another solution where the steps and the expected results are grouped for the same language. Sophie, thanks a lot for getting the feedback. When I think about it, also the 2nd approach can be parsed by a script. It is more complicated, probably more error prone but possible. Thus it can be moved into to really localized framework almost automatically as well. So, the second approach is probably the best temporary solution. Thanks for your investigation :) For information, I will try to organize a testing session on Moztrap for the 3.6.3 version with the FR project. May be we can try to organize a full session with very few languages, like may be DE, JA, FR at the same time? Also do you have an idea of the time needed (day per man dev) and the cost to make Moztrap fully localized (UI + content) ? Kind regards Sophie -- Sophie Gautier sophie.gaut...@documentfoundation.org Tel:+33683901545 Membership Certification Committee Member - Co-founder The Document Foundation ___ 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] Regression test (Moztrap) test case localization temporary solution.
Hi Sophie, Petr, all, Thanks for the discussion and sorry for the late response that I was busy of other works these days :( Visually the second one is also my most favorite, so let's start here. In this week, I will arrange time to update the test cases and make their format consistent with the prototype 2. http://vm12.documentfoundation.org/manage/case/99/ @Sophie, As for the 3.6.3 testing, do you have an estimation when would it be happening? Currently there are only English cases in the database migrated from Litmus. We will still need some time to migrate other language versions before arranging tests. Looking back to Litmus, there are 4 languages version of test cases: en/de/fr/pt-Br, if necessary we could also create Ja section awaiting for input. As for the l10n related hacking, they need large scope of changes in both frontend and backend. I would plan at least 1 dev month to do all the stuff including: Moztrap UI l10n implementing, test case l10n hacking and the relevant tests before they are good enough to be online. Best wishes, Yifan On Mon, Sep 03, 2012 at 07:57:22PM +0200, Sophie Gautier wrote: Hi Petr, all, On 03/09/2012 17:34, Petr Mladek wrote: [...] So the feedback from our team is the 2nd presentation that is preferred over the others, it seems to be more readable for all of them. May be we can go for the first presentation until we get more languages but do not forget about another solution where the steps and the expected results are grouped for the same language. Sophie, thanks a lot for getting the feedback. When I think about it, also the 2nd approach can be parsed by a script. It is more complicated, probably more error prone but possible. Thus it can be moved into to really localized framework almost automatically as well. So, the second approach is probably the best temporary solution. Thanks for your investigation :) For information, I will try to organize a testing session on Moztrap for the 3.6.3 version with the FR project. May be we can try to organize a full session with very few languages, like may be DE, JA, FR at the same time? Also do you have an idea of the time needed (day per man dev) and the cost to make Moztrap fully localized (UI + content) ? Kind regards Sophie -- 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/
