Re: git commit: Automate maintenance of the THANKS file
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 --
Re: git commit: Automate maintenance of the THANKS file
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 --
Re: git commit: Automate maintenance of the THANKS file
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 --
Re: git commit: Automate maintenance of the THANKS file
Speaking of that, can I ask to add me to THANKS file? ;) 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 --
Re: git commit: Automate maintenance of the THANKS file
I'm not sure I like this so much. Playing around with it, its a bit
prone to screw ups. 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.
Its also got Benoit in there twice since he made commits with slightly
different author/committer names which also seems awkward.
On Sun, Jun 17, 2012 at 1:29 PM, j...@apache.org wrote:
Updated Branches:
refs/heads/master 9514ed3f5 - 7646794ea
Automate maintenance of the THANKS file
THANKS now is automatically maintained for you. It uses git author
data to append people who submitted patches in the past.
For non-commit THANKS, you can still manually edit this file.
This commit removes from the THANKS file the people that appear
as git commit authors since we started committing them after
commit 6c976bd. These removed entries get automatically re-
added by `make`.
Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/7646794e
Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/7646794e
Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/7646794e
Branch: refs/heads/master
Commit: 7646794ea7a30d41a64c873d8b27ae830397d94a
Parents: 9514ed3
Author: Jan Lehnardt j...@apache.org
Authored: Sun Jun 17 20:06:21 2012 +0200
Committer: Jan Lehnardt j...@apache.org
Committed: Sun Jun 17 20:11:31 2012 +0200
--
Makefile.am | 10 +-
THANKS | 13 +
2 files changed, 14 insertions(+), 9 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/couchdb/blob/7646794e/Makefile.am
--
diff --git a/Makefile.am b/Makefile.am
index 9dd22b8..1cbd865 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -79,7 +79,15 @@ README.gz: $(top_srcdir)/README
-gzip -9 $ $@
THANKS.gz: $(top_srcdir)/THANKS
- -gzip -9 $ $@
+ sed -e 's/^#.*//' $ $.tmp # strip comments
+ sed -e '/^$$/d' $.tmp $.tmp2 # strip empty lines
+ git shortlog -se 6c976bd..HEAD \
+ | grep -v @apache.org \
+ | sed -E 's/^[[:blank:]]{5}[[:digit:]]+[[:blank:]]/ * /' \
+ $.tmp2 # inject git authors
+ echo '\nFor a list of authors see the `AUTHORS` file.\n' $.tmp2
+ -gzip -9 $.tmp2 $@ # zip
+ rm $.tmp $.tmp2 # cleanup
check: dev check-js
$(top_builddir)/test/etap/run $(top_srcdir)/test/etap
http://git-wip-us.apache.org/repos/asf/couchdb/blob/7646794e/THANKS
--
diff --git a/THANKS b/THANKS
index f0dccb8..1e065f8 100644
--- a/THANKS
+++ b/THANKS
@@ -66,7 +66,6 @@ suggesting improvements or submitting changes. Some of
these people are:
* Lim Yue Chuan shasder...@gmail.com
* David Davis xan...@xantus.org
* Klaus Trainer klaus.trai...@web.de
- * Dale Harvey d...@arandomurl.com
* Juuso Väänänen ju...@vaananen.org
* Jeff Zellner jeff.zell...@gmail.com
* Benjamin Young byo...@bigbluehat.com
@@ -92,12 +91,10 @@ suggesting improvements or submitting changes. Some of
these people are:
* Simon Leblanc sim.leblanc+apa...@gmail.com
* Rogutės Sparnuotos rogu...@googlemail.com
* Gavin McDonald gmcdon...@apache.org
- * Ronny Pfannschmidt ronny.pfannschm...@gmx.de
- * Magnus Hoff magh...@gmail.com
- * Alexander Dorofeev aka.s...@gmail.com
- * Anthony S Baker anthony.s.ba...@gmail.com
- * Ewan McDougall i...@mrloop.com
- * Adam Lofts adam.lo...@gmail.com
-For a list of authors see the `AUTHORS` file.
+# Dear committer who merges a commit from a non-committer:
+# You don't have to manually maintain the THANKS file anymore (yay!).
+# Non-committer authors get automatically appended to THANKS and
+# moved into THANKS.gz by `make`. This note will be stripped as well.
+# Authors from commit 6c976bd and onwards are auto-inserted.
Re: git commit: Automate maintenance of the THANKS file
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. 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. 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. 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.
Re: git commit: Automate maintenance of the THANKS file
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.
Re: git commit: Automate maintenance of the THANKS file
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 --
