On Tue, Jan 15, 2013 at 6:30 PM, Adam Williamson <awilliam@xxxxxxxxxx> 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. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
