couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: git commit: Automate maintenance of the THANKS file
Date Sun, 17 Jun 2012 20:02:25 GMT

On Jun 17, 2012, at 21:56 , Paul Davis wrote:

> On Sun, Jun 17, 2012 at 2:44 PM, Jan Lehnardt <> wrote:
>> On Jun 17, 2012, at 21:29 , Paul Davis wrote:
>>> I'm not sure I like this so much. Playing around with it, its a bit
>>> prone to screw ups.
>> I just don't want to maintain this file manually any more. It is
>> error-prone and makes merging user-contributions a pain. I'm happy
>> to have this implemented in any other way, but I think we should
>> try to remove any mechanical steps from maintaining our source if
>> we can. I hope you agree! :)
> Its an extra step but not one that I find to be particularly onerous.
> Given that we're already working on codifying merge practices I don't
> see why we don't just add a check box for "includes commit adding
> yourself to the THANKS file if this is your first contribution" that
> we look for.

That's a fair point, but this has annoyed me forever.

>>> It also breaks if AUTHORS.gz exists before you
>>> pull in new commits. We could solve that by forcing it to build every
>>> time but that's a bit of a hack for not much gain.
>> Can you explain how it breaks if AUTHORS.gz exists before the merge?
>> If you mean THANKS.gz, my idea was that this is only relevant on
>> packaging time (make distcheck) where THANKS.gz by definition does
>> not exist.
> I'm not sure its a good idea to have a file that is only built
> correctly in special circumstances.

I'm happy to add an rm -f $< to the target.

>>> Its also got Benoit in there twice since he made commits with slightly
>>> different author/committer names which also seems awkward.
>> The subsequent .mailmap commit fixes the dupes. The push emails seem
>> to be delayed atm, I reported this to danielsh on #asfinfra.
> I'm confused. You've removed one manually curated file only to add a
> new one that just modifies the build of the first? Seems like a lot of
> gymnastics.

.mailmap solves more than just this.

> In a perfect world I would be all in with you on this but
> unfortunately a large number of people don't spend time checking their
> user settings before pushing commits around. Instead of just adding
> people to a file the first time they make a commit this means I have
> to go and check that the THANKS file is generated properly and then
> maybe update .mailmap if not and recheck that I got it correct.

Fair enough, wanna revert?


View raw message