Criterion proposal - keyboard layouts

[drago01]

On Tue, Feb 21, 2012 at 10:27 AM, drago01 <drago01 at gmail.com> wrote:
> On Tue, Feb 21, 2012 at 12:42 AM, Adam Williamson <awilliam at redhat.com> wrote:
>> On Mon, 2012-02-20 at 20:59 +0100, drago01 wrote:
>>> We currently don't have any explicit criterion that mandates that
>>> keyboard layouts choose in the installer should work in the installed
>>> system.
>>> As a maintainer of one of the packages involved there
>>> (system-setup-keyboard) I see such bugs in basically every release,
>>> during the development cycle.
>>>
>>> We should pay more attention to such issues as a system that uses a
>>> different keyboard layout as the one physically present can not only
>>> be very annoying (we shouldn't release in that state) but
>>> can be useless when you have special characters in your password(s).
>>> (Can't easily decrypt / login).
>>>
>>> As seen in  https://lists.fedoraproject.org/pipermail/test/2011-March/097859.html
>>> we do currently have a paragraph that mentions this but is IMO way to
>>> vague.
>>>
>>> So I propose something like: "The keyboard layout selected in the
>>> installer must be in use after rebooting the installer (plymouth and
>>> X)".
>>
>> I wish I had better background on it, but I'm pretty sure we did discuss
>> having an explicit criterion before going with the 'vague' paragraph
>> instead. All that mail (by me) says is that I didn't think a specific
>> criterion 'worked well', which is pretty useless looking back - sigh.
>>
>> One problem I do remember is that, in practice, we don't really want to
>> block the release if a single extremely obscure keyboard layout turns
>> out to be broken at the last minute; that's one factor in favor of the
>> vague hand-wavey judgment call paragraph. We want to block only on
>> reasonably popularly-used layouts, your Frenches and Germans and
>> whatevers, but it's a bit hard to write a criterion that properly
>> restricts the list without being too restrictive.
>
> Well the proposed criterion is explicit and narrow if it works in
> anaconda it ought to work in the installed system. That means we have
> proper support for it but something went wrong when writing out the
> configuration. This is pretty straight forward to test and we
> shouldn't really release with such a bug hence why it should block.

So we hit such a bug again that is being proposed as a blocker for F17
... we might catch them earlier by having a clear criterion (for beta)

So any votes?