Re: [RFC][PATCH v9 0/6][BZ 10871] Month names in alternative grammatical case

[Zack Weinberg <zackw at panix dot com>]

On Wed, Oct 25, 2017 at 6:50 AM, Rafal Luzynski
<digitalfreak@lingonborough.com> wrote:
> 11.10.2017 19:47 Zack Weinberg <zackw@panix.com> wrote:
>> I plan to review this carefully, and perhaps go ahead and merge it,
>> next week if no one else gets to it first.
>
> I'm not sure if I understood you correctly.  Should I wait for your
> review and then go ahead and merge?  Then here is my ping.

Yes, I meant you should wait for my review, which I'm doing now.
Sorry for not getting to it "next week" as previously promised.

> 1. You asked me to write a documentation but I'm not sure which
> documentation you meant.  I updated NEWS, ChangeLog and some files
> in the manual directory.  But I'm not sure if this is sufficient, also
> I'd like to see at least one review.

I'll address this in replies to individual patches.

> 2. You asked me not to send the generated file locfile-kw.h to this list [2]
> so I have not sent it anymore.  But this file still needs to be pushed
> to git.  The patches are still available in bugzilla [3] and my github
> repo. [4] Should I merge them after the review and before pushing to master?

What you should do is drop the separate patches that regenerate
generated files from the patch series you send for review, but then,
right before pushing, for each patch, regenerate any
generated-but-checked-in files that will be altered by that patch and
check them in *as part of that commit*.

I sense that you are confused by both the request to not send
generated-but-checked-in files for review, and the desired procedure
for handling them in the commits that actually get pushed, so let me
explain why we do it this way:  First, we want
generated-but-checked-in files always to be up to date in the commit
history, so that "git bisect" works reliably.  So we want the
regenerated file to be checked in in the *same commit* that changes
what the generated file will be, always.  You can think of this as
mimicking how it would work if the file wasn't checked in: it would
get generated during the build in a state matching the actual source
code.  Second, we  don't review generated files, we review the code
that generates them, and generated files are often very long and
tedious to wade through, so we don't want them cluttering up the
emails we get. (But we *do* want them to be mentioned in your
ChangeLog entries so that we have the reminder right there that
generated-but -checked-in files are involved.  "* x/y/foo:
Regenerate." is enough.)

Some day we won't have any generated files checked into version
control, but until then this is the best compromise procedure we can
think of.  You might actually find it easier to edit the generated
files out of the output of "git format-patch" after the fact.

zw