glibc localedata bug reports

[Roland McGrath <roland at redhat dot com>]

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