Thanks :) On Jun 21, 2012, at 16:40 , Fedor Indutny wrote:
> Done ;) > > Cheers, > Fedor. > > > > On Thu, Jun 21, 2012 at 6:37 PM, Jan Lehnardt <j...@apache.org> wrote: > >> >> On Jun 18, 2012, at 12:29 , Fedor Indutny wrote: >> >>> Speaking of that, can I ask to add me to THANKS file? ;) >> >> Done, can you in turn close your PR on GitHub? :) >> >> Cheers >> Jan >> -- >> >> >>> >>> Cheers, >>> Fedor. >>> >>> >>> >>> On Mon, Jun 18, 2012 at 12:09 AM, Jan Lehnardt <j...@apache.org> wrote: >>> >>>> >>>> On Jun 17, 2012, at 22:05 , Paul Davis wrote: >>>> >>>>> On Sun, Jun 17, 2012 at 3:02 PM, Jan Lehnardt <j...@apache.org> wrote: >>>>>> >>>>>> On Jun 17, 2012, at 21:56 , Paul Davis wrote: >>>>>> >>>>>>> On Sun, Jun 17, 2012 at 2:44 PM, Jan Lehnardt <j...@apache.org> >> 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? >>>>>> >>>>>> Cheers >>>>>> Jan >>>>>> -- >>>>>> >>>>>> >>>>> >>>>> Playing with it a bit to see if I can make it build correctly and also >>>>> just build the AUTHORS file. I'll leave it around for a bit but won't >>>>> promise that the first time I spend more than 30s screwing with >>>>> mailmap that I revert it. >>>> >>>> Heh, that took me a while to get right :) >>>> >>>> Cheers >>>> Jan >>>> -- >>>> >>>> >>>> >> >>
