Re: Assuming consensus

[Rafal Luzynski <digitalfreak at lingonborough dot com>]

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