glibc localedata bug reports

glibc localedata bug reports

[Roland McGrath]

wrt http://sourceware.org/bugzilla/show_bug.cgi?id=1787

Locales folks, Dwayne is helping out with general glibc bugzilla triage,
and picking over the old reports.

Dwayne, localedata bugs are something of a special case.  The idea is that
there are fairly unambiguous objective criteria for localedata changes.
The information has to come from published official sources from the
governments of the localities in question, so competent delegates can
determine whether changes are appropriate, without further review by the
glibc maintainers.  The libc-locales mailing list is the default owner for
localedata.  Folks there know the localedata format issues and rules and
the international standards.  They've joined the list to volunteer their
efforts in reviewing localedata changes and new locales, and helping hone
outside contributions into correct changes in the proper form to go into libc.

My notion was to have a trusted person from the libc-locales list who signs
off on localedata changes that meet the criteria for inclusion.  We never
really got coherent procedures for this worked out.  I hope that we can get
this process in shape now as we get the general bugzilla procedures in
shape.  This person would be on the hook for verifying the submission is
appropriate in all regards, so I can let them go right in without worrying.

For some reports like 1787, you can easily see yourself that the changes
are OK in their content.  (You don't have to know much about localedata to
see that it's OK for a guy to update his own telephone number.)

localedata submissions have a few particular criteria for their content:
* References to official published government sources codifying the
  formatting details used in that locality.  
* Names using proper standard ISO codes.
* Verified working with glibc localedef/locale code.

In addition all glibc changes submitted need to meet some criteria:
* Copyright papers on file with FSF for authors and authors' employers.
  Contributors can tell you the state of this, but you need to verify it
  with the FSF's records.  The clerks are often slow to respond by email.
  To do final sign-off on new contributors' submissions, a person should
  have a gnu.org account so they can look in the file directly.
* Proper entries in the right ChangeLog.  Formatting must be correct,
  including the whitespace and TAB use.  Some places like localedata have a
  separate ChangeLog file; entries must be for the right file, with
  relative file names from the directory where that ChangeLog is.
  Entries must have "[BZ #nnn]" markers.

For convenience, ChangeLog entries should be separately pasted at the top
and not part of a patch.  The ideal for patches is so -p1 works from the
top libc directory (e.g. libc/localedata/foobar in a file name in diffs).
But -p0 is also fine, and -p1 or -p1 relative to localedata/ is acceptable
for localedata changes.  There is no reason to be especially picky about
that, as long as it's easy to apply the patch correctly.  For the same
reason, new files in patch form is usually easiest.

Copyright papers of course must be done properly and that is unavoidable.
For the other details it's up to you whether you want to put your efforts
into fixing up a submission or punt it back to the reporter to make their
own changes fit the proper form.


Thanks,
Roland

Re: glibc localedata bug reports

[Petter Reinholdtsen]

[Roland McGrath]
> Locales folks, Dwayne is helping out with general glibc bugzilla triage,
> and picking over the old reports.

Great.  :)

> Dwayne, localedata bugs are something of a special case.  The idea
> is that there are fairly unambiguous objective criteria for
> localedata changes.

Good idea, but in my experience, it is rarely in sync with reality.
In the not too uncommon and fairly lucky case, there are several
standard bodies in a country with competing and different locale
standards (for example norway, were the language authority and the
techical standard body made two slightly different set of rules. :).
In the more common and really unlucky case, there is no published
standard as the country in question have no standard body working on
these issues, or the standard body haven't yet addressed locale
issues.

> The information has to come from published official sources from the
> governments of the localities in question, so competent delegates
> can determine whether changes are appropriate, without further
> review by the glibc maintainers.

I've been unable so far to understand how to do this in a way that is
acceptable by the glibc maintainers, in the absence of "published
official sources from the governments of the localities in question",
and ran out of steam.  I hope Dwayne can take it further. :)

Re: glibc localedata bug reports

[Dwayne Grant McConnell]

On Mon, 7 Nov 2005, Roland McGrath wrote:

> wrt http://sourceware.org/bugzilla/show_bug.cgi?id=1787
> 
> Locales folks, Dwayne is helping out with general glibc bugzilla triage,
> and picking over the old reports.
> 
> Dwayne, localedata bugs are something of a special case.

Thanks for the detailed background! I'm making notes of things I learn as 
I start and I'll work all this info into a web page after a little of 
experience.

-- 
Dwayne Grant McConnell <decimal@us.ibm.com>
Lotus Notes Mail: Dwayne McConnell [Mail]/Austin/IBM@IBMUS
Lotus Notes Calendar: Dwayne McConnell [Calendar]/Austin/IBM@IBMUS