Message ID | 1362086831.305752.1535106956712@poczta.nazwa.pl |
---|---|
State | Committed |
Headers |
Received: (qmail 37750 invoked by alias); 24 Aug 2018 10:36:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 37681 invoked by uid 89); 24 Aug 2018 10:36:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-19.9 required=5.0 tests=AWL, BAYES_50, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_NONE, XPRIO autolearn=ham version=3.3.2 spammy=H*x:Mailer, H*UA:Mailer, H*UA:Open-Xchange, HImportance:Medium X-HELO: shared-ano163.rev.nazwa.pl X-Spam-Score: 2.249 Date: Fri, 24 Aug 2018 12:35:56 +0200 (CEST) From: Rafal Luzynski <digitalfreak@lingonborough.com> Reply-To: Rafal Luzynski <digitalfreak@lingonborough.com> To: GNU C Library <libc-alpha@sourceware.org> Cc: pravin.d.s@gmail.com Message-ID: <1362086831.305752.1535106956712@poczta.nazwa.pl> Subject: [PATCH] en_IN: Set the correct date format for "%x" (bug 17426). MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit |
Commit Message
Rafal Luzynski
Aug. 24, 2018, 10:35 a.m. UTC
[BZ #17426] * localedata/locales/en_IN (d_fmt): Use "%d/%m/%y". --- localedata/locales/en_IN | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Comments
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
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"