Re: Assuming consensus (was: Re: [PATCH] en_IN: Set the correct date format for "%x").

[Carlos O'Donell <carlos at redhat dot com>]

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.

-- 
Cheers,
Carlos.