Keyboard layout criterion

[drago01]

On Tue, Jan 15, 2013 at 6:30 PM, Adam Williamson <awilliam at redhat.com> wrote:
> On Tue, 2013-01-15 at 12:05 +0100, drago01 wrote:
>> Hi,
>>
>> I have already tried this multiple times in the past and we still have
>> nothing so lets try again ...
>>
>> The problem:
>> Keyboard layout settings and interactions seem to  break in almost
>> every release and we end up with multiple endless discussions whether
>> the issue is a blocker or not.
>>
>> The solution:
>> We should just add a release criteria that is clear enough so that we
>> can avoid this discussions and have a clear criteria to base "this is
>> a blocker".
>>
>>
>> So the proposed criteria (not sure whether we should require it for
>> beta or only final) is:
>>
>> "For new installations the keyboard layout selected in the installer
>> should be configured as default in the installed system.
>> This includes the encryption pass phrase entry, the virtual consoles,
>> the graphical login manager as well as the desktop environment.
>> For upgraded systems the same applies for the default keyboard layout
>> that was configured prior to the upgrade."
>>
>> This is as clear as it can be, there is no need to have some vague
>> text that leaves room for endless discussions.
>>
>> Any objections? Or can we finally get this done?
>
> Well, I don't mind, but I have one big objection and one small one. Big
> one: as things are, I'm not sure we can stand behind that. As written,
> we are not fulfilling it and cannot possibly fulfill it until
> https://bugzilla.redhat.com/show_bug.cgi?id=680990 and
> https://bugzilla.redhat.com/show_bug.cgi?id=837292 are fixed, because
> until that's done, https://bugzilla.redhat.com/show_bug.cgi?id=889562 is
> always going to exist for several hundred layouts.
>
> Even if we assume that gets done for F19, we have something like 400+
> layouts in the installer now. We can fudge the criterion at
> interpretation time and say 'well it's okay if just one or two really
> obscure ones are broken' but it might be nice if we could build that
> into the criterion itself - one of the complaints people have about the
> process currently is that there are cases where you have to 'know what
> the criterion really means', and it'd be nice to avoid as many of those
> as possible going forward.

How about defining a list of ones that must work? i.e to define what
"obscure" means.