Bug 473209

There is nothing to triage here.

Switching to ASSIGNED so that developers have responsibility to do whatever they want to do with it.

As always, adding languages to anaconda requires the following:

(1) What LANG= setting should we use for each?
(2) What's the console font that should be used?
(3) What's the console and X keyboard setting for each?
(4) What packages contain the X font?
(5) Are the font and keyboard settings complete and usable?

Parag did you forget to attach your patch?

not exactly that I forgot to attach patch here. I just took reference from this bug 237060 about how requests should be added to Bugzilla for newer languages in anaconda where no input was provided in that bug.

Created attachment 325481 [details]
Mai_IN_and_Ne_NP_lang addition patch

clumens,
      I have attached patch here. If information from patch is still not enough for criteria to add new language in anaconda then ask for required information.

Parag - yeah that's a good start, thanks.  If you look at scripts/upd-instroot, you'll see (among other things) that we need to include the font packages and the font files themselves.  Are there special fonts needed for these languages, or are they already part of a package we're including?  Also, in the rhpl package you'll see the keyboard_models.py file which needs similar changes to what you've already done.

For Maithili,
    defualt font set is from package lohit-fonts-maithili as seen in comps file.

For Nepali,
    defualt font set is from package madan-fonts as seen in comps file.

I am not sure yet about rhpl modification as I see only 4 Indic languages out of 11 got entry there and still rest have no entry for their keyboard. Will check on this and report new bug.

My understanding is that PCs in India normally use/have a US keyboard, right?

(In reply to comment #8)
> My understanding is that PCs in India normally use/have a US keyboard, right?
 Yes. Normally US keyboard is used.

What needs to be traiged here, that you moved this back to NEW?

Nothing needs to be triaged, but the bug is not assigned to anybody. As such, it belongs in NEW.

Sorry, it doesn't -- please take a look at https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow (note, that this is the official FESCO approved, workflow). If you need distinguish between ASSIGNED == "triaged, and the next destiny of the bug is up to maintainers" and "actually somebody works on it", I would suggest to use ON_DEV for it.

And yet it is interesting to note that there are *zero* Fedora anaconda bug reports in ON_DEV. Either this means that nobody is working on anything, or the "official FESCO approved workflow" doesn't actually reflect the reality of how bugs get sorted. It should be fairly obvious which of these is the case.

So now the question is whether to abide by the official documentation, or to go with the system that the rest of the people I work with actually use. I'd be inclined to choose the latter in any case unless there was a really compelling argument against it, and that's ignoring the fact that in /this case/ specifically, it's more helpful to this bug report for it to be marked as NEW rather than ASSIGNED - /because/ the general interpretation is that ASSIGNED means "Somebody is working on this bug", those bugs get less attention from everybody but their assignees. For bugs that are /actually/ being worked on that's not a problem, but for bugs that are still listed as assigned to anaconda-maint-list, it can drastically reduce turnaround time. In contrast, bugs marked as NEW are more likely to be looked at by non-assignees, increasing the likelihood of a response, quick fix, or assignation for fixing.

In addition, having checked with clumens, that workflow is based around releasing updates, which we don't do. It is, therefore, flawed.

(In reply to comment #13)
> specifically, it's more helpful to this bug report for it to be marked as NEW
> rather than ASSIGNED - /because/ the general interpretation is that ASSIGNED
> means "Somebody is working on this bug", those bugs get less attention from

No, it isn't and it actually never officially was (take a look for example at https://bugzilla.redhat.com/page.cgi?id=fields.html#assigned -- this text is there like forever). The problem with your interpretation is, that it doesn't take into account work of bug triagers, who if this stays in NEW, will hit this bug again and again and will switch it to ASSIGNED because there is nothing to triage here.

I totally understand that this is some work for you, but unfortunately, there are 4063 NEW bugs in Fedora bug triagers are struggling with, so I don't see any way how to change our ways easily.

> In addition, having checked with clumens, that workflow is based around
> releasing updates, which we don't do. It is, therefore, flawed.

OK, then I would please ask you to suggest how to move your bugs out of the NEW -- we can certainly help you, if there is a need to sift through a lot of bugs or something like that, but really NEW bugs should go away.

Please, catch me on IRC or anything, if you need to discuss it more.

Best,

Matěj Cepl

Why this bug gets moved back to NEW state whereas I have provided all required inputs here.

I think it would probably be better for the anaconda team to search for unassigned bugs than using state for that:

https://bugzilla.redhat.com/buglist.cgi?emailassigned_to1=1&emailtype1=exact&email1=anaconda-maint-list@redhat.com&product=Fedora&bug_status=NEW,ASSIGNED,NEEDINFO,MODIFIED (143 Fedora bugs)

You can of course narrow down more with &component=anaconda (142 bugs!) and more usefully &version={rawhide,10,..} (23, 82, 32, 5 bugs respectively).

https://bugzilla.redhat.com/buglist.cgi?product=Fedora&component=anaconda&bug_status=NEW,ASSIGNED,NEEDINFO,MODIFIED to see all open Fedora anaconda bugs, etc.  Probably good to bookmark and document on your wiki pages.

Parag - I see there's a special keyboard layout for Nepali (see /usr/share/X11/xkb/symbols/np), and that all the Indic languages have their layouts in /usr/share/X11/xkb/symbols/in as variants.  However, there is no variant for Maithili in that file.  Should I go ahead and use us for the keyboard layout as you indicated, or is another layout more appropriate?

That's the last bit of information required.

Yes. you are correct that we have xkb layouts already. But no one like to input in his locale at time of installation. people in India and so Nepal used to give input in English Characters only.
So I request you to please go ahead.

Right I don't think we should be using non-US xkb layouts for Indic languages by default - they do not support ascii input normally afaik.

any updates here or am I supposed to provide some more input?

Ping? Need to have this fixed before F11 Alpha freeze.

ping?

Since this doesn't require any new keyboard layouts defined, I believe it's all handled in the patch to anaconda that I just pushed.  This should therefore be fixed in the next build of anaconda.