As discussed with Igor, this test day will be hosted on 2011-03-03. [[BR]]
Igor, have you figured out which features/areas you want to target on? Do you plan to use the l10n template and specific test results page for it or the formatted wiki test day result page as before? [[BR]]
Thanks.
I think we need separate i18n/l10n test days as target can be different. Even we can add more than 1 test day.
if you want to have multiple test days on similar topics, one approach to consider is adding the second test day on tuesday or wednesday in the same week. We only list thursdays as open slots in the schedule, but actually if you want to run two test days in one week, on tuesday and thursday or wednesday and thursday, that's no problem, and we can just edit the table to add in the tuesday. that way it keeps all the events close together.
I prefer to use the formatted wiki test day result page as before. I intend to keep the l10n template just as a guide for translation teams to know which modules need testing, but it also have to be updated.
I'd like to give a special attention this time for langpack installation. Mainly regarding langpacks for Firefox 4 and Libre Office. And we also should target font rendering and input methods as usual.
We have two different groups of i18n test cases: installation and desktop related ones. So I'd divide the test days into those two groups rather than into i18n and l10n. Testers will hit both i18n and l10n bugs while running the tests anyway, and sometimes depending of the bug will be hard to figure out if it is a i18n or l10n bug at the moment, what can be done by further bug triage.
Of course we can try another approach, but since we have an intersection between l10n and i18n I think we can use it in our favor.
Replying to [comment:3 igor]:
I prefer to use the formatted wiki test day result page as before. I intend to keep the l10n template just as a guide for translation teams to know which modules need testing, but it also have to be updated. I'd like to give a special attention this time for langpack installation. Mainly regarding langpacks for Firefox 4 and Libre Office. And we also should target font rendering and input methods as usual. Langpack is good idea to test. Libre office has separate packages, but firefox don't have separate. Also we can test Language group support, which is by default installed by fedora (yum groupinstall <LANGUAGE>-support).
Langpack is good idea to test. Libre office has separate packages, but firefox don't have separate. Also we can test Language group support, which is by default installed by fedora (yum groupinstall <LANGUAGE>-support).
for Rendering and Input, we can have 4 basic test groups: - pango - gedit/firefox - qt - kwrite - icu - libre office - input - ibus - Printing - (can be print to file only - ps/pdf/svg)
installation and desktop can better idea than i18n/l10n grouping. Actually Rendering/Input/Font Testing requires few applications (as above), while for Basic translated Desktop we can test all default installed application (with desktop) for a language.
Can we use hybrid (mixed) approach? - installation - i18n/l10n (Single) - Desktop - two separate - l10n (Translation of default installed application) - i18n (input/rendering/printing) with one (or two) from each rendering engine.
Okay.
I used to host a yum langpack test day with Jens:
https://fedoraproject.org/wiki/Test_Day:2010-02-25_YumLangpackPlugin
I've added them in the [https://fedoraproject.org/wiki/Category:I18n_Desktop Category:I18n_desktop]. Feel free to add/polish the cases in need.
We have two different groups of i18n test cases: installation and desktop related ones.
Yeah, I divided the test cases into these two categories. At that time, I was confused about i18n and l10n, so I named all as i18n cases, where the translation tests should belong to l10n. I can change them to category:i18n/l10n cases. AFAIK the existing cases related to l10n/i18n are:
Replying to [comment:4 aalam]:
Replying to [comment:3 igor]: I prefer to use the formatted wiki test day result page as before. I intend to keep the l10n template just as a guide for translation teams to know which modules need testing, but it also have to be updated. I'd like to give a special attention this time for langpack installation. Mainly regarding langpacks for Firefox 4 and Libre Office. And we also should target font rendering and input methods as usual. Langpack is good idea to test. Libre office has separate packages, but firefox don't have separate. Also we can test Language group support, which is by default installed by fedora (yum groupinstall <LANGUAGE>-support). for Rendering and Input, we can have 4 basic test groups: - pango - gedit/firefox - qt - kwrite - icu - libre office - input - ibus - Printing - (can be print to file only - ps/pdf/svg) We have two different groups of i18n test cases: installation and desktop related ones. So I'd divide the test days into those two groups rather than into i18n and l10n. Testers will hit both i18n and l10n bugs while running the tests anyway, and sometimes depending of the bug will be hard to figure out if it is a i18n or l10n bug at the moment, what can be done by further bug triage. installation and desktop can better idea than i18n/l10n grouping. Actually Rendering/Input/Font Testing requires few applications (as above), while for Basic translated Desktop we can test all default installed application (with desktop) for a language. Of course we can try another approach, but since we have an intersection between l10n and i18n I think we can use it in our favor. Can we use hybrid (mixed) approach? - installation - i18n/l10n (Single) - Desktop - two separate - l10n (Translation of default installed application) - i18n (input/rendering/printing) with one (or two) from each rendering engine.
Installation tests can be hosted in one day, I've added Tuesday(2011-03-01) as installation test day like Adam suggested. How about the desktop part? If all of these are included, do you think one day is enough for desktop?
I think we need to use two days (Tuesday and Thursday or Wednesday and Thursday as Adam mentioned)
actually fedora translation deadline is 2011-03-15, we need to do translation testing after that (2011-03-17...). i18n part can be done before that.
Replying to [comment:6 rhe]:
Replying to [comment:4 aalam]: Can we use hybrid (mixed) approach? - installation - i18n/l10n (Single) - Desktop - two separate - l10n (Translation of default installed application) - i18n (input/rendering/printing) with one (or two) from each rendering engine.
It seems pretty straightforward to me. We definitively can manage the test days using this approach.
Although there are more things to be tested in comparison with the installation test day I think one day is enough for desktop. Since it includes different input methods used in many languages we might have people joining in different timezones. We also can include the langpack tests in the installation test day in order to balance the workload a little bit.
Replying to [comment:7 aalam]:
Installation tests can be hosted in one day, I've added Tuesday(2011-03-01) as installation test day like Adam suggested. How about the desktop part? If all of these are included, do you think one day is enough for desktop? I think we need to use two days (Tuesday and Thursday or Wednesday and Thursday as Adam mentioned)
Do you mean two days for desktop testing?
I see no problem in hosting translation testing after the string freeze and before the translation deadline. It looks like the optimal situation to me. It gives an opportunity for translators to do runtime checking. Otherwise, if they find a translation error after the translation deadline then maintainers could refuse to rebuild a package because of an error in a specific language or to change a string that will impact several languages, what could lead to translation rework after the deadline.
The downside is that we won't have all modules rebuilt with new translations until 2011-03-01. Anyway, we still have an open slot in 2011-03-17 but it is two close from translation deadline which might not give enough time for maintainers to rebuild their packages. I would suggest 2011-03-31 but I'm afraid it is too late in the release cycle.
Replying to [comment:9 igor]:
Replying to [comment:7 aalam]: Installation tests can be hosted in one day, I've added Tuesday(2011-03-01) as installation test day like Adam suggested. How about the desktop part? If all of these are included, do you think one day is enough for desktop? I think we need to use two days (Tuesday and Thursday or Wednesday and Thursday as Adam mentioned) Do you mean two days for desktop testing?
Yeah, I have the same concern. Currently the schedule is:
http://fedoraproject.org/wiki/QA/Fedora_15_test_days
actually fedora translation deadline is 2011-03-15, we need to do translation testing after that (2011-03-17...). i18n part can be done before that. I see no problem in hosting translation testing after the string freeze and before the translation deadline. It looks like the optimal situation to me. It gives an opportunity for translators to do runtime checking. Otherwise, if they find a translation error after the translation deadline then maintainers could refuse to rebuild a package because of an error in a specific language or to change a string that will impact several languages, what could lead to translation rework after the deadline. The downside is that we won't have all modules rebuilt with new translations until 2011-03-01. Anyway, we still have an open slot in 2011-03-17 but it is two close from translation deadline which might not give enough time for maintainers to rebuild their packages. I would suggest 2011-03-31 but I'm afraid it is too late in the release cycle.
Well, I'm a bit confused. First, for the i18n/l10n translation tests, the images used for testing are Alpha RCs provided by rel-eng, right? If yes, according to the schedule[1], 'Compose Alpha Candidate' is on 02-17, and 'create Beta Test Compose' is on 03-15. Will the new translations be included in Alpha RCs?
For i18n/l10n desktop tests, Will specific live image be built? Or should Alpha RC live image be used and then doing a fully update? Is 2011-03-03 ready for it?
Replying to [comment:7 aalam]: Installation tests can be hosted in one day, I've added Tuesday(2011-03-01) as installation test day like Adam suggested. How about the desktop part? If all of these are included, do you think one day is enough for desktop? I think we need to use two days (Tuesday and Thursday or Wednesday and Thursday as Adam mentioned) Do you mean two days for desktop testing? yes, it can be helpful if we will do i18n (limited application set) and l10n (major applications in default desktop) Testing. actually fedora translation deadline is 2011-03-15, we need to do translation testing after that (2011-03-17...). i18n part can be done before that. I see no problem in hosting translation testing after the string freeze and before the translation deadline. It looks like the optimal situation to me. It gives an opportunity for translators to do runtime checking. Otherwise, if they find a translation error after the translation deadline then maintainers could refuse to rebuild a package because of an error in a specific language or to change a string that will impact several languages, what could lead to translation rework after the deadline. The downside is that we won't have all modules rebuilt with new translations until 2011-03-01. Anyway, we still have an open slot in 2011-03-17 but it is two close from translation deadline which might not give enough time for maintainers to rebuild their packages. I would suggest 2011-03-31 but I'm afraid it is too late in the release cycle.
yes, it can be helpful if we will do i18n (limited application set) and l10n (major applications in default desktop) Testing.
yes, there is risk. packages may not be rebuild and if we test on 2011-03-31 , we expect that only critical issues can be fixed for i18n/l10n (with Beta). (One thing can be helpful is Gnome 3, translators can check gnome 3 translation once before release (April 04 is last day for translation)).
If we are going to do before translation deadline and find bug for translation, then it may be fixed before by translator and not too useful to report translation bug. So after translation deadline can be optimal time.
Right, but the new translations will only be included in Alpha RCs for those packages rebuilt by maintainers.
It is better to use a specific image for the l10n desktop tests, but it will be ready only by 2011-03-04, which is the date of the rebuild. The translation schedule [1] suggests to do string reviews in built UI between 2011-03-07 and 2011-03-15, which still is before the translation deadline.
Taking that in consideration I suggest the following dates:
2011-03-01: l10n/i18n Installation Test Day
2011-03-03: i18n Desktop Test Day
2011-03-08: l10n Desktop Test Day
I know that 2011-03-01 is before the deadline for packages rebuild but Anaconda is constantly rebuilt so I see no problem in hosting that day. 2011-03-03 is not affected by rebuild date since it is only for i18n testing. 2011-03-08 will be after the rebuild so translators can test both with an updated Alpha or with the specific live image for string review.
[1] http://poelstra.fedorapeople.org/schedules/f-15/f-15-trans-tasks.html
Replying to [comment:12 igor]:
Well, I'm a bit confused. First, for the i18n/l10n translation tests, the images used for testing are Alpha RCs provided by rel-eng, right? If yes, according to the schedule[1], 'Compose Alpha Candidate' is on 02-17, and 'create Beta Test Compose' is on 03-15. Will the new translations be included in Alpha RCs? Right, but the new translations will only be included in Alpha RCs for those packages rebuilt by maintainers. For i18n/l10n desktop tests, Will specific live image be built? Or should Alpha RC live image be used and then doing a fully update? Is 2011-03-03 ready for it? It is better to use a specific image for the l10n desktop tests, but it will be ready only by 2011-03-04, which is the date of the rebuild. The translation schedule [1] suggests to do string reviews in built UI between 2011-03-07 and 2011-03-15, which still is before the translation deadline. Taking that in consideration I suggest the following dates: 2011-03-01: l10n/i18n Installation Test Day 2011-03-03: i18n Desktop Test Day 2011-03-08: l10n Desktop Test Day I know that 2011-03-01 is before the deadline for packages rebuild but Anaconda is constantly rebuilt so I see no problem in hosting that day. 2011-03-03 is not affected by rebuild date since it is only for i18n testing. 2011-03-08 will be after the rebuild so translators can test both with an updated Alpha or with the specific live image for string review.
it looks good for me. Translators will get enough time to fix any issue before deadline.
Well, I'm a bit confused. First, for the i18n/l10n translation tests, the images used for testing are Alpha RCs provided by rel-eng, right? If yes, according to the schedule[1], 'Compose Alpha Candidate' is on 02-17, and 'create Beta Test Compose' is on 03-15. Will the new translations be included in Alpha RCs? Right, but the new translations will only be included in Alpha RCs for those packages rebuilt by maintainers. For i18n/l10n desktop tests, Will specific live image be built? Or should Alpha RC live image be used and then doing a fully update? Is 2011-03-03 ready for it? It is better to use a specific image for the l10n desktop tests, but it will be ready only by 2011-03-04, which is the date of the rebuild. The translation schedule [1] suggests to do string reviews in built UI between 2011-03-07 and 2011-03-15, which still is before the translation deadline. Taking that in consideration I suggest the following dates: 2011-03-01: l10n/i18n Installation Test Day 2011-03-03: i18n Desktop Test Day 2011-03-08: l10n Desktop Test Day I know that 2011-03-01 is before the deadline for packages rebuild but Anaconda is constantly rebuilt so I see no problem in hosting that day. 2011-03-03 is not affected by rebuild date since it is only for i18n testing. 2011-03-08 will be after the rebuild so translators can test both with an updated Alpha or with the specific live image for string review. [1] http://poelstra.fedorapeople.org/schedules/f-15/f-15-trans-tasks.html
Thanks for clarifying this. I've updated the schedule accordingly:
Replying to [comment:14 rhe]:
Thanks for clarifying this. I've updated the schedule accordingly: https://fedoraproject.org/wiki/QA/Fedora_15_test_days
Thank you! Since we have reached a consensus about the dates I'm doing a list of test cases we need to review.
So far we have:
Anything else to add here?
Replying to [comment:15 igor]:
Replying to [comment:14 rhe]: Thanks for clarifying this. I've updated the schedule accordingly: https://fedoraproject.org/wiki/QA/Fedora_15_test_days Thank you! Since we have reached a consensus about the dates I'm doing a list of test cases we need to review. So far we have: https://fedoraproject.org/wiki/Category:I18n_Installation https://fedoraproject.org/wiki/Category:I18n_Desktop https://fedoraproject.org/wiki/Category:IBus_Test_Cases https://fedoraproject.org/wiki/Category:Yum_Langpack_Test_Cases http://fedoraproject.org/wiki/QA:Fedora_14_l10n_Results_Template Anything else to add here?
Rendering (pango/qt/icu - those may be language specific) and Printing Test cases we can add. Also I would like to know about Gnome packages, even people may not directly translating, but it is Major part of Desktop.
Replying to [comment:16 aalam]:
In i18n installation test cases there are some post install procedures that are toolkit specific. We can move them to a separate test case in order to test pango/qt/icu rendering.
Testing GNOME translations might be tricky since they have their own schedule and procedures. I'd rather articulate this test along with upstream teams.
Continuing the work I started at FUDCon Tempe I have been updating our test cases for the upcoming test days. Here are some changes I made:
Replying to [comment:18 igor]:
Continuing the work I started at FUDCon Tempe I have been updating our test cases for the upcoming test days. Here are some changes I made: Post install procedures were moved from Category:I18n_Installation to Category:I18n_Desktop
Thanks, I also put the Yum Langpack Test Cases to that category.
Explicit step for checking language extensions was added to i18n_browsers test case as well as different toolkit testing. Add explicit step for testing LibreOffice on both Langpack_PackageKit_Application and Langpack Yum Application test cases Update Langpack test cases for using yum instead of downloading builds from koji manually
Great, it does improve a lot.
I also noticed that the following test cases might be redundant, since others cover the same scope. Those ones are now marked as old: https://fedoraproject.org/wiki/QA:Langpack_local_locale_install
Agree, now it's already covered by [https://fedoraproject.org/wiki/QA:Langpack_Yum_Application QA:Langpack_Yum_Application]
https://fedoraproject.org/wiki/QA:Testcase_i18n_font_desktop
This test aims to check the login and native text on desktop is correctly displayed and translated. I didn't find any case including this. Can you point it out?
https://fedoraproject.org/wiki/QA:Testcase_i18n_input_application
I guess you meant the [https://fedoraproject.org/wiki/QA:Testcase_ibus_input QA:Testcase_ibus_input] can replace it, right? [https://fedoraproject.org/wiki/QA:Testcase_ibus_input QA:Testcase_ibus_input] is more detailed, but hasn't been updated for a long time. Is there any step need be modified to adapt the F-15 test day?
BTW, I noticed [https://fedoraproject.org/wiki/QA:Testcase_i18n_default_fonts QA:Testcase_i18n_default_fonts] was created recently by Tagoh to check if fonts packages for your language is correctly installed by running a script. I think this is a good test. So we will use all the tests in [https://fedoraproject.org/wiki/Category:I18n_Installation Category:I18n_Installation] including it to the i18n/l10n installation Test day?
Replying to [comment:19 rhe]:
https://fedoraproject.org/wiki/QA:Testcase_i18n_font_desktop This test aims to check the login and native text on desktop is correctly displayed and translated. I didn't find any case including this. Can you point it out?
As far as I understand the test case https://fedoraproject.org/wiki/QA:Testcase_i18n_font_application has basically the same scope.
If you find that i18n_font_desktop is still valuable I can revert the change, no problem.
https://fedoraproject.org/wiki/QA:Testcase_i18n_input_application I guess you meant the [https://fedoraproject.org/wiki/QA:Testcase_ibus_input QA:Testcase_ibus_input] can replace it, right? [https://fedoraproject.org/wiki/QA:Testcase_ibus_input QA:Testcase_ibus_input] is more detailed, but hasn't been updated for a long time. Is there any step need be modified to adapt the F-15 test day?
Exactly, the ibus test case is far more detailed and seems to be version agnostic. I would like an opinion from aalam on this as well.
It's definitely a good test to include in the test day. I'll test the script in rawhide to see if it works ok or need an update.
Replying to [comment:20 igor]:
Replying to [comment:19 rhe]: https://fedoraproject.org/wiki/QA:Testcase_i18n_font_desktop This test aims to check the login and native text on desktop is correctly displayed and translated. I didn't find any case including this. Can you point it out? I tested gnome-shell, but gdm did not provide any way to select language or keyboard till today, not sure if we are able to follow step mentioned over there As far as I understand the test case https://fedoraproject.org/wiki/QA:Testcase_i18n_font_application has basically the same scope. If you find that i18n_font_desktop is still valuable I can revert the change, no problem. https://fedoraproject.org/wiki/QA:Testcase_i18n_input_application I guess you meant the [https://fedoraproject.org/wiki/QA:Testcase_ibus_input QA:Testcase_ibus_input] can replace it, right? [https://fedoraproject.org/wiki/QA:Testcase_ibus_input QA:Testcase_ibus_input] is more detailed, but hasn't been updated for a long time. Is there any step need be modified to adapt the F-15 test day? Exactly, the ibus test case is far more detailed and seems to be version agnostic. I would like an opinion from aalam on this as well. https://fedoraproject.org/wiki/QA:Testcase_i18n_input_application can co-exist with ibus test cases as it helps to enable/disable ibus (with im-chooser). It can be modified to test only im-chooser.
I tested gnome-shell, but gdm did not provide any way to select language or keyboard till today, not sure if we are able to follow step mentioned over there
https://fedoraproject.org/wiki/QA:Testcase_i18n_input_application can co-exist with ibus test cases as it helps to enable/disable ibus (with im-chooser). It can be modified to test only im-chooser.
Can we add bugs (already filed or fixed) on test pages, so that people can easily test issue (or possible issues) (like gnome-shell and ibus bug: https://bugzilla.redhat.com/show_bug.cgi?id=669481)
FYI: I placed draft pages for all i18n/l10n Test Days on wiki, as follows: * https://fedoraproject.org/wiki/Test_Day:2011-03-01_L10n_i18n_Installation * https://fedoraproject.org/wiki/Test_Day:2011-03-03_I18n_Desktop * https://fedoraproject.org/wiki/Test_Day:2011-03-08_L10n_Desktop
Replying to [comment:21 aalam]:
I believe they are working on that but if it's not available until the test day we can change that step for using system-config-language.
Ok change reverted and test case added to Test Day page.
Good idea! Added to the i18n desktop test day page as a nice to test situation.
Replying to [comment:22 igor]:
Thank you, I adjusted them a bit using [https://fedoraproject.org/wiki/QA/Test_Days/Template current test day page format].
Replying to [comment:21 aalam]: I tested gnome-shell, but gdm did not provide any way to select language or keyboard till today, not sure if we are able to follow step mentioned over there I believe they are working on that but if it's not available until the test day we can change that step for using system-config-language.
I saw this problem as well. I think it's important to configure them at gdm or through an alternative way. AFAIK, Using system-config-language requires reboot to work, that will limit the use of live image chosen by most testers.
https://fedoraproject.org/wiki/QA:Testcase_i18n_input_application can co-exist with ibus test cases as it helps to enable/disable ibus (with im-chooser). It can be modified to test only im-chooser. Ok change reverted and test case added to Test Day page.
AFAIK Im-chooser test is covered by [https://fedoraproject.org/wiki/QA:Testcase_i18n_input_method QA:Testcase_i18n_input_method], isn't it?
Can we add bugs (already filed or fixed) on test pages, so that people can easily test issue (or possible issues) (like gnome-shell and ibus bug: https://bugzilla.redhat.com/show_bug.cgi?id=669481) Good idea! Added to the i18n desktop test day page as a nice to test situation. +1.
Good idea! Added to the i18n desktop test day page as a nice to test situation. +1.
Btw, for the [https://fedoraproject.org/wiki/QA:Testcase_i18n_font_desktop font desktop test], it is to check the fonts displayed on the desktop including the menus. This is not included in the [https://fedoraproject.org/wiki/QA:Testcase_i18n_font_application font application test] which aims to check the fonts in an application. So I prefer to keep both in the test day.
A good person to have in CC for this (if he's not already) would be Takao Fujiwara, who works on ibus and is looking after getting ibus integrated with GNOME Shell. We definitely need to check GNOME 3's i18n/l10n smarts, I wanted to do it as part of the GNOME 3 test days but didn't manage to get test cases in for the first one. I will add Takao to CC, assuming it works (trac's CC field is a bit weird).
Replying to [comment:23 rhe]:
Replying to [comment:21 aalam]: I tested gnome-shell, but gdm did not provide any way to select language or keyboard till today, not sure if we are able to follow step mentioned over there I believe they are working on that but if it's not available until the test day we can change that step for using system-config-language. I saw this problem as well. I think it's important to configure them at gdm or through an alternative way. AFAIK, Using system-config-language requires reboot to work, that will limit the use of live image chosen by most testers.
If GNOME is able to log off (it hangs sometimes) then s-c-language works on live images. I added steps for this on [https://fedoraproject.org/wiki/QA:Testcase_i18n_font_application font application test]. I also realize that using GNOME's language selector application is not an option since it's not system-wide therefore doesn't reflect on GDM strings.
Since accessing menus are part of running applications I added a few steps to include menus rendering on [https://fedoraproject.org/wiki/QA:Testcase_i18n_font_application font application test]. IMHO we don't need separated test cases for menus and application, having both on the same test case can keep tests more straightforward.
Replying to [comment:25 igor]:
Replying to [comment:23 rhe]: Replying to [comment:21 aalam]: I tested gnome-shell, but gdm did not provide any way to select language or keyboard till today, not sure if we are able to follow step mentioned over there I believe they are working on that but if it's not available until the test day we can change that step for using system-config-language. I saw this problem as well. I think it's important to configure them at gdm or through an alternative way. AFAIK, Using system-config-language requires reboot to work, that will limit the use of live image chosen by most testers. If GNOME is able to log off (it hangs sometimes) then s-c-language works on live images. I added steps for this on [https://fedoraproject.org/wiki/QA:Testcase_i18n_font_application font application test]. I also realize that using GNOME's language selector application is not an option since it's not system-wide therefore doesn't reflect on GDM strings. Okay, thanks for clarifying this. Btw, for the [https://fedoraproject.org/wiki/QA:Testcase_i18n_font_desktop font desktop test], it is to check the fonts displayed on the desktop including the menus. This is not included in the [https://fedoraproject.org/wiki/QA:Testcase_i18n_font_application font application test] which aims to check the fonts in an application. So I prefer to keep both in the test day. Since accessing menus are part of running applications I added a few steps to include menus rendering on [https://fedoraproject.org/wiki/QA:Testcase_i18n_font_application font application test]. IMHO we don't need separated test cases for menus and application, having both on the same test case can keep tests more straightforward.
Okay, thanks for clarifying this.
It makes sense to me. Thanks.
Hi Igor,
L10n desktop test day is coming tomorrow, I noticed [https://fedoraproject.org/wiki/Test_Day:2011-03-08_L10n_Desktop#Test_Results the example of a test result] is a link to the template page. Do you want testers directly post their results to your template page? I think it's better to create another result page based on the template, so I created [https://fedoraproject.org/wiki/QA:Fedora_15_l10n_Results_2011-03-08] with a few adjustments, feel free to change it. Besides, some packages have no steps(ie. issue command), should we add another way to test them? And for the column 'built status', what is this supposed to be? Do we need this column in the result page? Please don't forget to send out the announcement when you are satisfied with them. Thanks.:)
Replying to [comment:27 rhe]:
Hi Igor, L10n desktop test day is coming tomorrow, I noticed [https://fedoraproject.org/wiki/Test_Day:2011-03-08_L10n_Desktop#Test_Results the example of a test result] is a link to the template page. Do you want testers directly post their results to your template page? I think it's better to create another result page based on the template, so I created [https://fedoraproject.org/wiki/QA:Fedora_15_l10n_Results_2011-03-08] with a few adjustments, feel free to change it. Besides, some packages have no steps(ie. issue command), should we add another way to test them? And for the column 'built status', what is this supposed to be? Do we need this column in the result page? Please don't forget to send out the announcement when you are satisfied with them. Thanks.:)
What I had in mind for this was that translations teams could use the template to create a new page and link that page into the Test Day page. I came up with this approach because I thought that just one result page could be confusing since we will have results for several languages. Probably I should have documented it better. Since we already have result on your page due to timezones differences we can keep using it, no problem. I'll just add a language tag information to the header so new testers can add this information.
Those few packages who have no steps are usually hard to deploy packages. For instance smoon, the smolt server, which there are no straightforward way to test. We definitively need to come up with a way to test those packages for next releases test days but ask translators to set up a whole environment certainly is not a good idea. Although not optimal for the test day, translators can still review the .PO file.
That column "build status" was something I kept from the first template made by Noriko. I guess she wanted to keep track of packaging status by that time. For the test days I really don't see much use for this column so I can remove it from the results page you have created.
I'll send the test day announcement shortly.
What's the purpose of the link under 'Test Cases' which points to https://fedoraproject.org/wiki/QA:Fedora_15_l10n_Results_Template ? It's not a test case, and it just seems wrong to me; should it be removed?
Announcement sent to -test-announce and L10N list.
Replying to [comment:29 adamwill]:
That was because the results template were supposed to work as test cases here, for translators know what packages to test. Since Hurry changed it to one results page for all teams that link isn't necessary anymore so I removed it.
Replying to [comment:30 igor]:
Announcement sent to -test-announce and L10N list. Replying to [comment:29 adamwill]: What's the purpose of the link under 'Test Cases' which points to https://fedoraproject.org/wiki/QA:Fedora_15_l10n_Results_Template ? It's not a test case, and it just seems wrong to me; should it be removed? That was because the results template were supposed to work as test cases here, for translators know what packages to test. Since Hurry changed it to one results page for all teams that link isn't necessary anymore so I removed it.
The page looks better, and I like the idea to use lang_CODE in result status.:) I've also redirected [https://fedoraproject.org/wiki/Test_Day:Current current page] to this test day and changed irc topic on #fedora-test-day. So let's get it started!
Test Days recap sent to test-announce mailing list.
It is always a pleasure working with you guys. Thanks Hurry, Alam and Adam for your help, contributions and suggestions. :)
Log in to comment on this ticket.