Ticket #81 (reopened enhancement)

Opened 4 years ago

Last modified 14 months ago

Add i18n release criteria

Reported by: jlaska Owned by:
Priority: major Milestone: Fedora 14
Component: Release criteria Version:
Keywords: retrospective Cc: test@…
Blocked By: Blocking:

Description

problem

See RHBZ#571900 - Keyboard mapping not correct (USA instead of Belgium) when first login after install Fedora 13 Alpha

analysis

  • Currently we don't have i18n installation cases, so local language install is not tested as a demand. Untranslated pages are still existing after RC test. Such cases needed be added in test as well as release criteria.
  • Does the Fedora i18n team have any release criteria to propose?
  • RHBZ #571900 pointed out the need for a better understanding of how the language and keymap installer selections impact the installed system.

enhancement recommendation

Recommend reviewing the release criteria to ensure expectations are captured around propagating language and keymap settings from install to desktop login (/etc/sysconfig/i18n, image:Package-x-generic-16.pnggdm etc...). It may also be advised to coordinate with the installer team so that bugs can be filed for any missing functionality.

Change History

comment:1 Changed 4 years ago by adamwill

Note that we did do some 'workarounds' in the existing criteria for this, late in F13 cycle. We added some keyboard layout testing to an existing install validation test case - https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_%28encrypted%29_install - and added a desktop validation test case which does i18n - https://fedoraproject.org/wiki/QA:Testcase_desktop_login . (Though we seem to have left that out of the validation tables for late F13 builds). I agree we should capture this in the release criteria explicitly.

comment:2 Changed 2 years ago by adamwill

  • Resolution set to fixed
  • Status changed from new to closed

We finally added i18n criteria during the F16 cycle. See https://lists.fedoraproject.org/pipermail/test/2011-October/103588.html .

The criterion that was added was "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use".

Earlier, we added a preamble to the criteria which experience has shown sufficiently covers "propagating language and keymap settings from install to desktop login" - we usually are able to discuss keymap issues on the basis of the existing criteria plus the preamble language about 'specific configurations'.

comment:3 Changed 19 months ago by adamwill

  • Resolution fixed deleted
  • Status changed from closed to reopened

On second thoughts, re-opening this; the criteria judo required to cover keymap issues is kind of heavy and probably doesn't pass the raptor test. If the whole team of 'experienced' blocker review people were eaten by raptors tomorrow, I'm not sure someone coming in and doing the blocker review process from scratch would figure out the process hack of 'keymap selection failing is a violation of the 'encrypted partition passphrase entry' criterion in the case of a non-default keymap'. It's a clever process hack, but it's hardly transparent. So it may be desirable to have more explicit criteria for keymap selection still.

comment:4 Changed 18 months ago by johannbg

Unless you are going to move the entire software translation deadline ahead of alpha ( and all related criteria and test case ) the solution is to move the "encrypted partition passphrase entry" criterion for alpha to beta where it belong.

I think it's time that the QA community stops chasing the broken development process anaconda is following by changing adjusting our release criteria everyday trying to meet it. That truly is something *they* need to fix in-house, including how every release cycle they manage to break the keyboard/key mapping selection

comment:5 Changed 14 months ago by tflink

  • Cc test@… added
  • Component changed from Wiki to Release criteria

Changing component to be more appropriate (and test new cc system)

Note: See TracTickets for help on using tickets.