en_IN: Set the correct date format for "%x" (bug 17426).

  [BZ #17426]
	* localedata/locales/en_IN (d_fmt): Use "%d/%m/%y".
---
 localedata/locales/en_IN | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
  

On 08/24/2018 06:35 AM, Rafal Luzynski wrote:
> 	[BZ #17426]
> 	* localedata/locales/en_IN (d_fmt): Use "%d/%m/%y".
> ---
>  localedata/locales/en_IN | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/localedata/locales/en_IN b/localedata/locales/en_IN
> index c8afec9..32cfe85 100644
> --- a/localedata/locales/en_IN
> +++ b/localedata/locales/en_IN
> @@ -104,8 +104,8 @@ am_pm       "AM";"PM"
>  % Appropriate date and time representation
>  d_t_fmt     "%A %d %B %Y %I:%M:%S %p %Z"
>  %
> -% Appropriate date representation
> -d_fmt       "%A %d %B %Y"
> +% Appropriate date representation (%x)
> +d_fmt       "%d//%m//%y"
>  %
>  % Appropriate time representation
>  t_fmt       "%I:%M:%S  %Z"
> 

As localedata subsystem maintainer you have the right to assume consensus
here and commit this patch immediately. If you are looking for additional
review you should clarify that. I have no opinion on the bug itself (I
haven't reviewed it).
  

25.08.2018 04:38 Carlos O'Donell <carlos@redhat.com> wrote:
> [...]
> As localedata subsystem maintainer you have the right to assume consensus
> here and commit this patch immediately. If you are looking for additional
> review you should clarify that.

You have repeated this statement multiple times already so I'm afraid there
is a misunderstanding at my side.  So far I've been trying to follow the
Contribution Checklist [1] as closely as possible, that is:

1. Attach the patch to a Bugzilla report.
2. Post it to libc-alpha.
3. Wait some time to let the people express their concerns.
   By "some time" I mean about 1 week (usually less).
4. If there is no feedback or if there is a positive feedback or
   if we are short of time (e.g., the patch must be applied before a release
   which is scheduled in few days) then I assume consensus and push to master.

I understand that usually there will be no feedback because the change may
apply to a language that none of us can speak, or (rare case) it may apply
to a language which I can speak but few or no other people here can.  Of course,
I always try to gather the data from reliable sources and approach the native
speakers.

Optionally, if a change is trivial, nondestructive, and I am absolutely sure
it is correct (like improving comments or fixing an obvious typo) then I:

1. Push the patch to master immediately.
2. Post it to libc-alpha as PATCH COMMITTED.

Do you mean that I should not post the locale data patches to libc-alpha
and push them immediately to master, as long as I have performed a sufficient
research off-list?  Should I post the patches after pushing (as PATCH COMMITTED)
or should I also skip this step?

A simple yes/no answer will be sufficient for me.

> I have no opinion on the bug itself (I
> haven't reviewed it).

BTW, I think it needs a further work, that means: the patch is correct but
the same change may be needed for more locales.

Regards,

Rafal


[1] https://sourceware.org/glibc/wiki/Contribution%20checklist
  

On 08/27/2018 12:41 PM, Rafal Luzynski wrote:
> 25.08.2018 04:38 Carlos O'Donell <carlos@redhat.com> wrote:
>> [...]
>> As localedata subsystem maintainer you have the right to assume consensus
>> here and commit this patch immediately. If you are looking for additional
>> review you should clarify that.
> 
> You have repeated this statement multiple times already so I'm afraid there
> is a misunderstanding at my side.  So far I've been trying to follow the
> Contribution Checklist [1] as closely as possible, that is:
> 
> 1. Attach the patch to a Bugzilla report.
> 2. Post it to libc-alpha.
> 3. Wait some time to let the people express their concerns.
>     By "some time" I mean about 1 week (usually less).
> 4. If there is no feedback or if there is a positive feedback or
>     if we are short of time (e.g., the patch must be applied before a release
>     which is scheduled in few days) then I assume consensus and push to master.

<https://sourceware.org/glibc/wiki/MAINTAINERS#Reviewers_by_component> 
says “ Where someone is listed in the Maintainers column, they may at 
their discretion consider their own patches in that area to have 
consensus without waiting for third-party review […]”.

> Do you mean that I should not post the locale data patches to libc-alpha
> and push them immediately to master, as long as I have performed a sufficient
> research off-list?  Should I post the patches after pushing (as PATCH COMMITTED)
> or should I also skip this step?

All patches should be posted to the mailing list at least once.  But the 
documented intend is that for subsystem maintainers, they can post and 
commit at the same time.  But you are right this is done rarely.

Thanks,
Florian
  

On 08/27/2018 06:41 AM, Rafal Luzynski wrote:
> 25.08.2018 04:38 Carlos O'Donell <carlos@redhat.com> wrote:
>> [...]
>> As localedata subsystem maintainer you have the right to assume consensus
>> here and commit this patch immediately. If you are looking for additional
>> review you should clarify that.
> 
> You have repeated this statement multiple times already so I'm afraid there
> is a misunderstanding at my side.  So far I've been trying to follow the
> Contribution Checklist [1] as closely as possible, that is:
> 
> 1. Attach the patch to a Bugzilla report.
> 2. Post it to libc-alpha.
> 3. Wait some time to let the people express their concerns.
>    By "some time" I mean about 1 week (usually less).
> 4. If there is no feedback or if there is a positive feedback or
>    if we are short of time (e.g., the patch must be applied before a release
>    which is scheduled in few days) then I assume consensus and push to master.
> 
> I understand that usually there will be no feedback because the change may
> apply to a language that none of us can speak, or (rare case) it may apply
> to a language which I can speak but few or no other people here can.  Of course,
> I always try to gather the data from reliable sources and approach the native
> speakers.

Patches from subsystem maintainers generally fall into two categories:

(1) those patches you know are correct.

(2) those patches you are concerned might need more input.

The patch you just posted 'Set the correct date format for "%x"' seems to
fall into the category of (1), where you did the research, and have what you
expect is a correct change (please correct me if I'm wrong).

My suggestion to you is to push the patch *and* post it as:

'[COMMITTED] en_IN: Set the correct date format for "%x"'

As subsystem maintainer you can assume consensus, commit the patch, and then
post the list with COMMITTED to show other developers what work you did, and
perhaps comment if they have time.

You may always post patches that fall into (2), but if they are for a subsystem
for which you are a maintainer, you should explicitly call out what kind of
feedback you are looking for, either review, or double checking, since it's
assumed you have consensus.

> Optionally, if a change is trivial, nondestructive, and I am absolutely sure
> it is correct (like improving comments or fixing an obvious typo) then I:
> 
> 1. Push the patch to master immediately.
> 2. Post it to libc-alpha as PATCH COMMITTED.
> 
> Do you mean that I should not post the locale data patches to libc-alpha
> and push them immediately to master, as long as I have performed a sufficient
> research off-list?  Should I post the patches after pushing (as PATCH COMMITTED)
> or should I also skip this step?

> A simple yes/no answer will be sufficient for me.

You should post the patch to libc-alpha, and you should use [COMMITTED] as
your prefix, and immediately commit the patch, as long as you think it
is correct.

I hope this answers your questions.

My intent is to remove obstacles that might slow you down from making progress.

>> I have no opinion on the bug itself (I
>> haven't reviewed it).
> 
> BTW, I think it needs a further work, that means: the patch is correct but
> the same change may be needed for more locales.

That's OK, you can commit this in stages, so long as after each commit the
result is a glibc that still builds and passes all regression tests.
  

27.08.2018 21:53 Carlos O'Donell <carlos@redhat.com> wrote:
> [...]
> The patch you just posted 'Set the correct date format for "%x"' seems to
> fall into the category of (1), where you did the research, and have what you
> expect is a correct change (please correct me if I'm wrong).

You are correct.  Except that, according to Murphy's law, every piece of code
(including a bugfix) may still contain a bug. :-)

> My suggestion to you is to push the patch *and* post it as:
>
> '[COMMITTED] en_IN: Set the correct date format for "%x"'

You convinced me and I will also explain that below.  I will commit this
patch now but I will not post it again because it has been posted already.

> As subsystem maintainer you can assume consensus, commit the patch, and then
> post the list with COMMITTED to show other developers what work you did, and
> perhaps comment if they have time.
>
> You may always post patches that fall into (2), but if they are for a
> subsystem
> for which you are a maintainer, you should explicitly call out what kind of
> feedback you are looking for, either review, or double checking, since it's
> assumed you have consensus.

Usually I expect some feedback from the native speakers but I usually reach
them outside of this list.  OK, next time I will explain what kind of feedback
I expect and I will commit the patch immediately in case it is not reasonable
to ask for a feedback in this list.

> [...]
> I hope this answers your questions.

Yes, it answers completely.  Thank you.

> My intent is to remove obstacles that might slow you down from making
> progress.

Thank you.  Indeed, I'm often working slowly but that's because I'm a casual
contributor and I contribute only in my free time which I don't have much.
That's out of your reach, unfortunately.  On the other hand, committing fast
will
not speed up my work.  I can commit fast or instead start working on another
issue
while waiting for the feedback.  The total bug per year factor will be the same.

> >> I have no opinion on the bug itself (I
> >> haven't reviewed it).
> >
> > BTW, I think it needs a further work, that means: the patch is correct but
> > the same change may be needed for more locales.
>
> That's OK, you can commit this in stages, so long as after each commit the
> result is a glibc that still builds and passes all regression tests.

I think it is very reasonable to push the patch for en_IN even if it does not
fix the problem completely.  AFAIK en_IN is commonly used in India and as soon
as I commit this patch it will help build a convenient test environment for
some of my Indian friends who hopefully will provide me some feedback.

Also, thank you Florian for your answer.  I have read it but I don't reply to
every
message to avoid noise.

Best regards,

Rafal
  

This patch has been pushed to master.  Please note that it does not
close the issue because the same or similar change is probably required
to all (or almost all) *_IN locales.  The missing fix will be provided
ASAP.

Regards,

Rafal