Re: Promoting Git developers
On Mon, Mar 16, 2015 at 6:06 PM, Stefan Beller sbel...@google.com wrote: On Mon, Mar 16, 2015 at 2:20 AM, David Kastrup d...@gnu.org wrote: Git Annotate? Git Praise as opposed to blame? Git Who as a pun on the subcommand structure which doesn't always follows grammar? Yeah these suggestions above are nice, thanks for them, but Git Rev News also look a bit like git rev-list and git rev-parse which are plumbing Git commands, so it gives a somewhat hardcore look to the news letter which I like. Thanks, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Sun, Mar 15, 2015 at 11:18 PM, Junio C Hamano gits...@pobox.com wrote: Christian Couder christian.cou...@gmail.com writes: I wrote something about a potential Git Rev News news letter: I read it. Sounds promising. Thanks! [...] I obviously do not know how the actual contents would look like at this point, but depending on the quality of the publication I might be able to steal some descriptions when keeping the notes on topics in flight that appear in my What's cooking report. And it can go the other way around, too. The publication may want to peek my What's cooking report for hints on how to characterize each topic and assess its impact to the evolution of Git. Yeah, it would be a very nice thing if we could steal these kind of things from each other's work! Thanks, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Christian Couder christian.cou...@gmail.com writes: On Mon, Mar 16, 2015 at 6:06 PM, Stefan Beller sbel...@google.com wrote: On Mon, Mar 16, 2015 at 2:20 AM, David Kastrup d...@gnu.org wrote: Git Annotate? Git Praise as opposed to blame? Git Who as a pun on the subcommand structure which doesn't always follows grammar? Yeah these suggestions above are nice, thanks for them, but Git Rev News also look a bit like git rev-list and git rev-parse which are plumbing Git commands, so it gives a somewhat hardcore look to the news letter which I like. Call that Git Rev List then to be more direct? I myself liked the Review (spelled in full word) as its non-nerdy sound, as a suitable name for a publication that bridges between hard-core developers and slightly-more-serious-than-casual observers, but its not my call (and as I often say, I am not good at naming things) ;-). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Sun, Mar 15, 2015 at 9:46 AM, Christian Couder christian.cou...@gmail.com wrote: I wrote something about a potential Git Rev News news letter: https://github.com/git/git.github.io/pull/15 I would love to have/use something like this in the GitMinutes podcast. Perhaps in addition to the very random interview format that I have now, I could do a more regular episodes about Git news, where I incorporate this. I also volunteer to help with the production, if you'll allow list lurkers like myself to contribute ;) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Tue, Mar 17, 2015 at 10:43 AM, Thomas Ferris Nicolaisen tfn...@gmail.com wrote: On Sun, Mar 15, 2015 at 9:46 AM, Christian Couder christian.cou...@gmail.com wrote: I wrote something about a potential Git Rev News news letter: https://github.com/git/git.github.io/pull/15 I would love to have/use something like this in the GitMinutes podcast. Perhaps in addition to the very random interview format that I have now, I could do a more regular episodes about Git news, where I incorporate this. Yeah, no problem. I also volunteer to help with the production, if you'll allow list lurkers like myself to contribute ;) Yes of course, you are very welcome! Peff, could you also give the rights on the repo to Thomas? Thanks both, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Sun, 15 Mar 2015, Junio C Hamano wrote: Christian Couder christian.cou...@gmail.com writes: I wrote something about a potential Git Rev News news letter: I read it. Sounds promising. Just one suggestion on the name and half a comment. How would Git Review (or Git Monthly Review, or replace your favourite how-often-per-period-ly in its name) sound? I meant it to sound similar to academic journals that summarize and review contemporary works in the field and keeps your original pun about our culture around patch reviews. I obviously do not know how the actual contents would look like at this point, but depending on the quality of the publication I might be able to steal some descriptions when keeping the notes on topics in flight that appear in my What's cooking report. And it can go the other way around, too. The publication may want to peek my What's cooking report for hints on how to characterize each topic and assess its impact to the evolution of Git. I'll bet that LWN would publish, or at least link to, such articles on a regular basis, and if you end up doing an in-depth writeup on a particularly discussed topic, they would probably give it pretty good visibility. David Lang -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Mon, Mar 16, 2015 at 2:20 AM, David Kastrup d...@gnu.org wrote: Git Annotate? Git Praise as opposed to blame? Git Who as a pun on the subcommand structure which doesn't always follows grammar? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
David Lang da...@lang.hm writes: On Sun, 15 Mar 2015, Junio C Hamano wrote: Christian Couder christian.cou...@gmail.com writes: I wrote something about a potential Git Rev News news letter: I read it. Sounds promising. Just one suggestion on the name and half a comment. How would Git Review (or Git Monthly Review, or replace your favourite how-often-per-period-ly in its name) sound? I meant it to sound similar to academic journals that summarize and review contemporary works in the field and keeps your original pun about our culture around patch reviews. ... I'll bet that LWN would publish, or at least link to, such articles on a regular basis, and if you end up doing an in-depth writeup on a particularly discussed topic, they would probably give it pretty good visibility. I hope you are right, but my observation of our coverage by lwn.net is somewhat pessimistic. In our early days, our progress often used to appear on the Kernel Development page, which I presume is the most important page of the weekly for the kernel developers, but in several months, the mention of us has moved two pages back to Development and listed together with folks like OCaml Weekly, PostgreSQL Weekly, etc. I would not count that as pretty good visibility particularly. I am taking it as a positive change, though. Once we got stable enough not to be a roadblock for the kernel folks and proven ourselves not to regress, our progress probably ceased to be newsworthy to them ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Mon, 16 Mar 2015, Junio C Hamano wrote: David Lang da...@lang.hm writes: On Sun, 15 Mar 2015, Junio C Hamano wrote: Christian Couder christian.cou...@gmail.com writes: I wrote something about a potential Git Rev News news letter: I read it. Sounds promising. Just one suggestion on the name and half a comment. How would Git Review (or Git Monthly Review, or replace your favourite how-often-per-period-ly in its name) sound? I meant it to sound similar to academic journals that summarize and review contemporary works in the field and keeps your original pun about our culture around patch reviews. ... I'll bet that LWN would publish, or at least link to, such articles on a regular basis, and if you end up doing an in-depth writeup on a particularly discussed topic, they would probably give it pretty good visibility. I hope you are right, but my observation of our coverage by lwn.net is somewhat pessimistic. In our early days, our progress often used to appear on the Kernel Development page, which I presume is the most important page of the weekly for the kernel developers, but in several months, the mention of us has moved two pages back to Development and listed together with folks like OCaml Weekly, PostgreSQL Weekly, etc. I would not count that as pretty good visibility particularly. I am taking it as a positive change, though. Once we got stable enough not to be a roadblock for the kernel folks and proven ourselves not to regress, our progress probably ceased to be newsworthy to them ;-) It ceased to be about kernel development, and fell into the normal development bucket :-) Routine release notes (like your notes from the maintainer) do end up just getting links to them as you have seen. But if someone is summarizing the discussions on the mailing list, those will be a bit more interesting, and if there is a particularly hot topic, the summary of that discussion can be a full fledged article on it's own. David Lang -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Sun, Mar 15, 2015 at 11:43 PM, Randall S. Becker rsbec...@nexbridge.com wrote: On March 15, 2015 6:19 PM Christian Couder wrote: snip Just one suggestion on the name and half a comment. How would Git Review (or Git Monthly Review, or replace your favourite how-often-per-period-ly in its name) sound? I meant it to sound similar to academic journals that summarize and review contemporary works in the field and keeps your original pun about our culture around patch reviews. I would be ok for that but there is already this Gerrit related command: http://www.mediawiki.org/wiki/Gerrit/git-review Maybe I can just use Git Rev, but it doesn't tell that it is about news? If I may humbly offer the suggestion that Git Blame would be a far more appropriate pun as a name :) You don't want me to steal Junio's blog title: http://git-blame.blogspot.fr/ don't you? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Christian Couder christian.cou...@gmail.com writes: On Sun, Mar 15, 2015 at 11:43 PM, Randall S. Becker rsbec...@nexbridge.com wrote: On March 15, 2015 6:19 PM Christian Couder wrote: snip Just one suggestion on the name and half a comment. How would Git Review (or Git Monthly Review, or replace your favourite how-often-per-period-ly in its name) sound? I meant it to sound similar to academic journals that summarize and review contemporary works in the field and keeps your original pun about our culture around patch reviews. I would be ok for that but there is already this Gerrit related command: http://www.mediawiki.org/wiki/Gerrit/git-review Maybe I can just use Git Rev, but it doesn't tell that it is about news? If I may humbly offer the suggestion that Git Blame would be a far more appropriate pun as a name :) You don't want me to steal Junio's blog title: http://git-blame.blogspot.fr/ don't you? Git Annotate? -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Thu, Mar 12, 2015 at 11:58 PM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: Seeing my name in shortlog was nice, but not that exciting. I submitted a patch, it was taken, and of course it ends up in any automated lists of authors. What was much more rewarding was being mentioned specifically in A note from the maintainer as a helpful person. That had much more value because: 1. It was one of a handful of names. 2. It was picked by a human. So in that sense, it is quite the opposite of including shortlog output in the release announcements (I still think the shortlog thing we have been discussing is a good thing, but not at the same level). Yes, and that cuts both ways, unfortunately. There always will be I am doing more reviews than X and my reviews are higher quality. Why was X singled out and got thanked but not me?, X is really doing a good job reviewing in this cycle, but could other people who send reviews of lessor quality (to my mind) feel that it is unjustified if I thanked X and nobody else?, etc. A mechanically generated list avoids these issues, but the satisfaction you get from being on the list is not very high, exactly because it is not hand picked. I think it is still much better to have some people positively hand picked than nothing. People who have not been hand picked despite having done something they think is of the same or higher quality can always ask privately about the reason they haven't been hand picked or they can try again expecting that the outcome will be different next time. Anyway if some people are positively hand picked you can always hope that it will happen to you, while otherwise there is no hope at all. I do not know that it is worth having a Best of 2015 Git awards ceremony, but it is sometimes nice to thank people personally when you appreciate their efforts. I sometimes mail people off-list to do so. Yeah, I do the same, but revealing that we do so would defeat what we tried to achieve by doing so off-list in the first place. Now those who haven't got such a piece of e-mail for a while can start to suspect that they have fallen out of favour or something ;-(. I don't think it defeat anything. I think you could even do it more online. Best, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Wed, Mar 11, 2015 at 9:42 PM, Junio C Hamano gits...@pobox.com wrote: Christian Couder christian.cou...@gmail.com writes: On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano gits...@pobox.com wrote: I would suspect that those who agree with you would appreciate if you or somebody volunteered to act as our CKDO (chief kudos distribution officer). I do not think I have enough time to do that well. One good place to start might be to scan the list and summarize something like the following on weekly or monthly basis, as these are not something you can get by pointing people to git shortlog output. - Those who gave helpful review comments, how about going this way illustration patches, etc. Bonus points to those who helped onboarding newcomers. - Those who asked pertinent questions on common pain points, and those who answered them helpfully. Ok, I can start something about this two points every week or every few week. It would be best if I could get help from at least one person as I think it is a lot of work. No kidding; even though it may no longer be an impossibly large task as in the infrationary epoch reported in the Git Traffic, this forum is still a high traffic place. I wrote something about a potential Git Rev News news letter: https://github.com/git/git.github.io/pull/15 Peff, could you give me write access so that I don't need to send pull requests? If some people are interested to contribute even if it is only sporadically, I would suggest they ask for write access too. I also appreciate very much that you are willing to improve the release notes by adding a summary with people's names. Just in case you misunderstood, I do not think it is a good idea to add names to release notes and I will not do so. I was and am planning add the list of contributors at the end of the e-mail when the release notes is sent out, i.e. in the Announce message that is sent to the list (and CC'ed to lwn.net). Ok, that is already very nice. Thanks, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Christian Couder christian.cou...@gmail.com writes: I wrote something about a potential Git Rev News news letter: I read it. Sounds promising. Just one suggestion on the name and half a comment. How would Git Review (or Git Monthly Review, or replace your favourite how-often-per-period-ly in its name) sound? I meant it to sound similar to academic journals that summarize and review contemporary works in the field and keeps your original pun about our culture around patch reviews. I obviously do not know how the actual contents would look like at this point, but depending on the quality of the publication I might be able to steal some descriptions when keeping the notes on topics in flight that appear in my What's cooking report. And it can go the other way around, too. The publication may want to peek my What's cooking report for hints on how to characterize each topic and assess its impact to the evolution of Git. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Promoting Git developers
On March 15, 2015 6:19 PM Christian Couder wrote: snip Just one suggestion on the name and half a comment. How would Git Review (or Git Monthly Review, or replace your favourite how-often-per-period-ly in its name) sound? I meant it to sound similar to academic journals that summarize and review contemporary works in the field and keeps your original pun about our culture around patch reviews. If I may humbly offer the suggestion that Git Blame would be a far more appropriate pun as a name :) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Wed, Mar 11, 2015 at 09:53:22PM -0700, Junio C Hamano wrote: I'd first suggest to employ icase to unify *-By and *-by. Perhaps we would want a recommended list somewhere in SubmittingPatches to discourage people from getting too creative? There's already such list in SubmittingPatches, so there's already quite a few to choose from: Also notice that a real name is used in the Signed-off-by: line. Please don't hide your real name. If you like, you can put extra tags at the end: 1. Reported-by: is used to credit someone who found the bug that the patch attempts to fix. 2. Acked-by: says that the person who is more familiar with the area the patch attempts to modify liked the patch. 3. Reviewed-by:, unlike the other tags, can only be offered by the reviewer and means that she is completely satisfied that the patch is ready for application. It is usually offered only after a detailed review. 4. Tested-by: is used to indicate that the person applied the patch and found it to have the desired effect. You can also create your own tag or use one that's in common usage such as Thanks-to:, Based-on-patch-by:, or Mentored-by:. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Fredrik Gustafsson iv...@iveqy.com writes: On Wed, Mar 11, 2015 at 09:53:22PM -0700, Junio C Hamano wrote: I'd first suggest to employ icase to unify *-By and *-by. Perhaps we would want a recommended list somewhere in SubmittingPatches to discourage people from getting too creative? There's already such list in SubmittingPatches, so there's already quite a few to choose from: Also notice that a real name is used in the Signed-off-by: line. Please don't hide your real name. If you like, you can put extra tags at the end: 1. Reported-by: is used to credit someone who found the bug that the patch attempts to fix. 2. Acked-by: says that the person who is more familiar with the area the patch attempts to modify liked the patch. 3. Reviewed-by:, unlike the other tags, can only be offered by the reviewer and means that she is completely satisfied that the patch is ready for application. It is usually offered only after a detailed review. 4. Tested-by: is used to indicate that the person applied the patch and found it to have the desired effect. You can also create your own tag or use one that's in common usage such as Thanks-to:, Based-on-patch-by:, or Mentored-by:. Hmph, the first step might be to drop that last sentence, I guess, if we consider this a mess and if we want to clean it up. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Wed, Mar 11, 2015 at 02:28:03PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: Or something along those lines. The wording and indentation of the message could probably use tweaking. And there is a bash-ism in the script. :) OK, I've updated the Announce script on the 'todo' branch. The announcement for 2.3.2 I sent out earlier as $gmane/264975 would have looked like this. Thanks, I think the organization and wording you chose look nice. One minor nit, though: The latest maintenance release Git v2.3.2 is now available at the usual places. It comprises of 41 non-merge commits since v2.3.1, contributed by 19 people, 5 of which are new faces. It's not generally considered correct to use of with the active tense of comprise. So either: It comprises 41 non-merge commits... or: It is comprised of 41 non-merge commits... is fine. The latter is much more common, at least in American English, though I imagine it gives some prescriptivists headaches. New contributors who made this release possible are as follows. Welcome to the Git development community! Aleksander Boruch-Gruszecki, Aleksey Vasenev, Patrick Steinhardt, Ryuichi Kokubo, and Tom G. Christensen. I hadn't thought about it when I originally suggested this, but of course new is not strictly meaningful in a world with branches. If you contribute a bugfix on top of v2.0.0 that goes to maint, do you get to be new in v2.0.1 _and_ in v2.2.0? I do not think it matters too much either way in practice, but I guess it would depend on your approach (picking the old base manually, or by using all tags prior to the released version). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Jeff King p...@peff.net writes: Seeing my name in shortlog was nice, but not that exciting. I submitted a patch, it was taken, and of course it ends up in any automated lists of authors. What was much more rewarding was being mentioned specifically in A note from the maintainer as a helpful person. That had much more value because: 1. It was one of a handful of names. 2. It was picked by a human. So in that sense, it is quite the opposite of including shortlog output in the release announcements (I still think the shortlog thing we have been discussing is a good thing, but not at the same level). Yes, and that cuts both ways, unfortunately. There always will be I am doing more reviews than X and my reviews are higher quality. Why was X singled out and got thanked but not me?, X is really doing a good job reviewing in this cycle, but could other people who send reviews of lessor quality (to my mind) feel that it is unjustified if I thanked X and nobody else?, etc. A mechanically generated list avoids these issues, but the satisfaction you get from being on the list is not very high, exactly because it is not hand picked. I do not know that it is worth having a Best of 2015 Git awards ceremony, but it is sometimes nice to thank people personally when you appreciate their efforts. I sometimes mail people off-list to do so. Yeah, I do the same, but revealing that we do so would defeat what we tried to achieve by doing so off-list in the first place. Now those who haven't got such a piece of e-mail for a while can start to suspect that they have fallen out of favour or something ;-(. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Jeff King p...@peff.net writes: It is comprised of 41 non-merge commits... is fine. Thanks; very much appreciated. New contributors who made this release possible are as follows. Welcome to the Git development community! Aleksander Boruch-Gruszecki, Aleksey Vasenev, Patrick Steinhardt, Ryuichi Kokubo, and Tom G. Christensen. I hadn't thought about it when I originally suggested this, but of course new is not strictly meaningful in a world with branches. If you contribute a bugfix on top of v2.0.0 that goes to maint, do you get to be new in v2.0.1 _and_ in v2.2.0? Yeah, tricky. How about New contributors whose contributions weren't in $previous are as follows. Welcome to the Git development community! Then after merging a topic to 'master' and then 'maint' and when cutting v2.3.3, a new person will be listed as not in v2.3.2 and then again in the announcement for v2.4.0, as not in v2.3.0. Yes, it is cheating, but that would match the story the shortlog at the end would tell. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Wed, Mar 11, 2015 at 10:05:43PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: I spent many years as a type C contributor, and I remember how nice it was to see my name mentioned occasionally as a useful person. I guess that everybody is different ;-) After throwing a small patch at ROCKbox (git.rockbox.org) back when they were still hosted on Subversion, I felt somewhat ashamed to see my name appear in their CREDITS file because the change I made was so insignificant. In such a flat list like that, you cannot tell who made significant contributions over time and who are just a casual drive-by contributor like me, unless you know the community and who are important in the community. Heh. Actually, after writing that, I almost clarified, but did not think anybody was that interested. But since you replied...:) Seeing my name in shortlog was nice, but not that exciting. I submitted a patch, it was taken, and of course it ends up in any automated lists of authors. What was much more rewarding was being mentioned specifically in A note from the maintainer as a helpful person. That had much more value because: 1. It was one of a handful of names. 2. It was picked by a human. So in that sense, it is quite the opposite of including shortlog output in the release announcements (I still think the shortlog thing we have been discussing is a good thing, but not at the same level). I do not know that it is worth having a Best of 2015 Git awards ceremony, but it is sometimes nice to thank people personally when you appreciate their efforts. I sometimes mail people off-list to do so. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Thu, Mar 12, 2015 at 03:36:46PM -0700, Junio C Hamano wrote: I hadn't thought about it when I originally suggested this, but of course new is not strictly meaningful in a world with branches. If you contribute a bugfix on top of v2.0.0 that goes to maint, do you get to be new in v2.0.1 _and_ in v2.2.0? Yeah, tricky. How about New contributors whose contributions weren't in $previous are as follows. Welcome to the Git development community! Yeah, that makes a lot of sense to me, and then we can have it in both places. I suspect the releases from master get a lot more readers, but if we had to pick only one, people with bugfixes would generally be mentioned in maint announcements. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Jeff King p...@peff.net writes: Or something along those lines. The wording and indentation of the message could probably use tweaking. And there is a bash-ism in the script. :) OK, I've updated the Announce script on the 'todo' branch. The announcement for 2.3.2 I sent out earlier as $gmane/264975 would have looked like this. -- 8 -- To: git@vger.kernel.org Cc: Linux Kernel linux-ker...@vger.kernel.org Bcc: l...@lwn.net Subject: [ANNOUNCE] Git v2.3.2 The latest maintenance release Git v2.3.2 is now available at the usual places. It comprises of 41 non-merge commits since v2.3.1, contributed by 19 people, 5 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.3.2' tag and the 'maint' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git New contributors who made this release possible are as follows. Welcome to the Git development community! Aleksander Boruch-Gruszecki, Aleksey Vasenev, Patrick Steinhardt, Ryuichi Kokubo, and Tom G. Christensen. Returning contributors who helped this release are as follows. Thanks for your continued support. Alexander Kuleshov, Eric Sunshine, Jeff King, Jonathon Mah, Junio C Hamano, Kirill A. Shutemov, Kyle J. McKay, Matthieu Moy, Mike Hommey, Ramsay Allan Jones, René Scharfe, Stefan Beller, Torsten Bögershausen, and Дилян Палаузов. Git v2.3.2 Release Notes Fixes since v2.3.1 -- * update-index --refresh used to leak when an entry cannot be refreshed for whatever reason. ... * Even though we officially haven't dropped Perl 5.8 support, the Getopt::Long package that came with it does not support --no- prefix to negate a boolean option; manually add support to help people with older Getopt::Long package. Also contains typofixes, documentation updates and trivial code clean-ups. Changes since v2.3.1 are as follows: Aleksander Boruch-Gruszecki (1): merge-file: correctly open files when in a subdir Aleksey Vasenev (1): wincred: fix get credential if username has @ ... Дилян Палаузов (1): do not include the same header twice -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Christian Couder christian.cou...@gmail.com writes: On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano gits...@pobox.com wrote: I would suspect that those who agree with you would appreciate if you or somebody volunteered to act as our CKDO (chief kudos distribution officer). I do not think I have enough time to do that well. One good place to start might be to scan the list and summarize something like the following on weekly or monthly basis, as these are not something you can get by pointing people to git shortlog output. - Those who gave helpful review comments, how about going this way illustration patches, etc. Bonus points to those who helped onboarding newcomers. - Those who asked pertinent questions on common pain points, and those who answered them helpfully. Ok, I can start something about this two points every week or every few week. It would be best if I could get help from at least one person as I think it is a lot of work. No kidding; even though it may no longer be an impossibly large task as in the infrationary epoch reported in the Git Traffic, this forum is still a high traffic place. I also appreciate very much that you are willing to improve the release notes by adding a summary with people's names. Just in case you misunderstood, I do not think it is a good idea to add names to release notes and I will not do so. I was and am planning add the list of contributors at the end of the e-mail when the release notes is sent out, i.e. in the Announce message that is sent to the list (and CC'ed to lwn.net). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On 12 March 2015 at 08:28, Junio C Hamano gits...@pobox.com wrote: OK, I've updated the Announce script on the 'todo' branch. The announcement for 2.3.2 I sent out earlier as $gmane/264975 would have looked like this. I think the changes are excellent, and think they add a lot of value regardless of any other measures that might be introduced, such as Git Traffic. At the least it gives long time lurkers, and people who skim the list, an easy way to put 'names to code', and it promotes the very people who should be promoted. Thanks to everyone involved in making this happen. Regards, Andrew Ardill -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Wed, Mar 11, 2015 at 12:31 AM, Jeff King p...@peff.net wrote: On Tue, Mar 10, 2015 at 07:36:34PM -0700, Junio C Hamano wrote: Or if that would make the release notes too cumbersome to review, what about using systemd's method? systemd's release notes include a contributions from section at the very end that lists everyone with a patch included in the release. I can add shortlog --no-merges -s -n v2.3.0..v2.4.0 at the end of the e-mail when the release notes is sent out. That might be a good enough balance between the usefulness of the release notes to its customers and giving credits to individuals in a way a bit more visible than if you are interested, run shortlog yourself [*4*]. I somehow thought you already did this, but it looks like you just do shortlog (without the -ns) for the maint release announcement. That is because (a) it is scripted in Meta/Announce, and (b) I strip it out for feature releases, as the plain shortlog output with full feature list is usually ends up being just too long for the announce message. Perhaps I'll add shortlog -s | pr -3 or something at the end for both maintenance track and feature releases. Names only, unordered and hopefully not overly long. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Wed, Mar 11, 2015 at 12:38:21AM -0700, Junio C Hamano wrote: I can add shortlog --no-merges -s -n v2.3.0..v2.4.0 at the end of the e-mail when the release notes is sent out. That might be a good enough balance between the usefulness of the release notes to its customers and giving credits to individuals in a way a bit more visible than if you are interested, run shortlog yourself [*4*]. I somehow thought you already did this, but it looks like you just do shortlog (without the -ns) for the maint release announcement. That is because (a) it is scripted in Meta/Announce, and (b) I strip it out for feature releases, as the plain shortlog output with full feature list is usually ends up being just too long for the announce message. Yeah, I figured the length was the reason. Perhaps I'll add shortlog -s | pr -3 or something at the end for both maintenance track and feature releases. Names only, unordered and hopefully not overly long. Yes, I was thinking something along those lines. Maybe: # example old=v2.2.0 new=v2.3.0 # like shortlog -s, but we do not even care about the numbers shortlog () { git log --format=%aN $@ | sort -u } compact () { perl -lne 'push @x, $_; END { print join(, , @x) }' | fold -s } count () { shortlog $old..$new | wc -l } newbies () { comm -23 (shortlog $old..$new) (shortlog $old) | compact } oldtimers () { comm -12 (shortlog $old..$new) (shortlog $old) | compact } cat EOF Git $new was developed with commits from $(count) people. Thanks very much to our returning developers: $(oldtimers) and welcome to new contributors in this release: $(newbies) EOF Or something along those lines. The wording and indentation of the message could probably use tweaking. And there is a bash-ism in the script. :) -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Tue, Mar 10, 2015 at 07:36:34PM -0700, Junio C Hamano wrote: Or if that would make the release notes too cumbersome to review, what about using systemd's method? systemd's release notes include a contributions from section at the very end that lists everyone with a patch included in the release. I can add shortlog --no-merges -s -n v2.3.0..v2.4.0 at the end of the e-mail when the release notes is sent out. That might be a good enough balance between the usefulness of the release notes to its customers and giving credits to individuals in a way a bit more visible than if you are interested, run shortlog yourself [*4*]. I somehow thought you already did this, but it looks like you just do shortlog (without the -ns) for the maint release announcement. This does seem like a very simple thing we could to promote visibility of contributors, and one would that would not require any ongoing effort once it is initially scripted. It may even be a nice place to specifically call out contributors who are new in this release. I spent many years as a type C contributor, and I remember how nice it was to see my name mentioned occasionally as a useful person. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano gits...@pobox.com wrote: Christian Couder christian.cou...@gmail.com writes: I don't want to write again about each of these points now. I am more interested in discussing a good strategy to try to revert the sad trend of Git developers being promoted less and less, because I think that it is really very important. I would suspect that those who agree with you would appreciate if you or somebody volunteered to act as our CKDO (chief kudos distribution officer). I do not think I have enough time to do that well. One good place to start might be to scan the list and summarize something like the following on weekly or monthly basis, as these are not something you can get by pointing people to git shortlog output. - Those who gave helpful review comments, how about going this way illustration patches, etc. Bonus points to those who helped onboarding newcomers. - Those who asked pertinent questions on common pain points, and those who answered them helpfully. Ok, I can start something about this two points every week or every few week. It would be best if I could get help from at least one person as I think it is a lot of work. We can perhaps use the Git Developer Site at https://github.com/git/git.github.io to edit a new page collaboratively that would be published on http://git.github.io/ and after that send an email to the mailing list. If you are more ambitious, the source of the kudos may want to cover activities outside of this mailing list (e.g. giving talks and tutorials at conferences, etc.). First I don't know if we should really give kudos (or badges) or have something more like the former Git Traffic you talk about in another email (or perhaps both). And then I expect that if people give talks or tutorials at conferences or publish a blog post or have other news they want to share, they could edit the web page themselves on GitHub (or fork it and send a pull request if they don't have the rights). I also appreciate very much that you are willing to improve the release notes by adding a summary with people's names. It would be nice if we could also have somewhere on a web page at least a good listing of the authors and how many commits they had contributed (since the beginning and maybe also during the last year). We could also add other listings made using the Helped-by and Reviewed-by trailers. I don't think we should rely on an external web site like OpenHub (which is still giving me a 504 Gateway Time-out on the contributor page) or even the (broken) contributor graph on GitHub for that. If Scott and Peff don't want it on git-scm.com then it is of course better on git.github.io than nowhere. Thanks, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Duy Nguyen pclo...@gmail.com writes: On Wed, Mar 11, 2015 at 11:16 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: ... We may want to acknowledge review efforts as well, by grepping Helped-by:, Reviewed-by:... Agreed. Something along the lines of $ git shortlog --no-merges -s -n -t Helped-by -t Reviewed-by v2.3.0.. A quick grep/uniq/sort gives this 1512 Acked-by 537 Reviewed-by 389 Reported-by 317 Helped-by 147 Tested-by 143 Suggested-by 97 Noticed-by 78 Improved-by 49 Thanks-to 40 Mentored-by 23 Requested-by 21 Acked-By 20 Inspired-by 18 Based-on-patch-by 9 Explained-by 9 Contributions-by It looks like people are quite creative. I think all these *-by (so -t supports wildcards) and Thanks-to: could be also considered as contribution. I'd first suggest to employ icase to unify *-By and *-by. Perhaps we would want a recommended list somewhere in SubmittingPatches to discourage people from getting too creative? Acked and Reviewed would be part of the normal review process. Reported, Requested, Noticed, Suggested, Inspired, and Based-on-patch-by are about where the motivation to make the change came from. They try to express modes of communication and degree of involvement of the named person in the process of germinating an idea, and the nature of the change (is it a bug or is it an improvement?), but I wonder if we can standardize these into just a few (or just one) by shedding the various nuances. If the difference these various phrases try to convey is so important, it probably deserves to be in the log message proper (e.g. instead of Inspired-by, say In his blog at $URL, ... expressed frustration in doing ...; this will solve that issue in such and such way in the log, and use the standard trailer that designates where the idea came from). People named by these trailers are the ones that connect us to end users by noticing and relaying their pain points, and by working with us to improve Git. We would want to credit them no less than we do an author of a casual here is a typofix in a comment patch. And everything else above looks Helped-by to me. Again, the different phrases try to convey what kind of help in polishing the change was, but if that is worth expressing, it probably belongs to the log message itself (e.g. instead of Explained-by, say The above explanation was given by ... in $gmane/1369525 in the log message and use Helped-by). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Jeff King p...@peff.net writes: I spent many years as a type C contributor, and I remember how nice it was to see my name mentioned occasionally as a useful person. I guess that everybody is different ;-) After throwing a small patch at ROCKbox (git.rockbox.org) back when they were still hosted on Subversion, I felt somewhat ashamed to see my name appear in their CREDITS file because the change I made was so insignificant. In such a flat list like that, you cannot tell who made significant contributions over time and who are just a casual drive-by contributor like me, unless you know the community and who are important in the community. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Wed, Mar 11, 2015 at 11:16 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: ... We may want to acknowledge review efforts as well, by grepping Helped-by:, Reviewed-by:... Agreed. Something along the lines of $ git shortlog --no-merges -s -n -t Helped-by -t Reviewed-by v2.3.0.. A quick grep/uniq/sort gives this 1512 Acked-by 537 Reviewed-by 389 Reported-by 317 Helped-by 147 Tested-by 143 Suggested-by 97 Noticed-by 78 Improved-by 49 Thanks-to 40 Mentored-by 23 Requested-by 21 Acked-By 20 Inspired-by 18 Based-on-patch-by 9 Explained-by 9 Contributions-by It looks like people are quite creative. I think all these *-by (so -t supports wildcards) and Thanks-to: could be also considered as contribution. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers (was: Bashing freelancers)
On Mon, Mar 9, 2015 at 2:57 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: Christian Couder venit, vidit, dixit 07.03.2015 08:18: Hi, On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup d...@gnu.org wrote: At some point of time I think it may be worth reevaluating the toxic atmosphere against freelancers doing Git development. My opinion on this is that the Git community has not been good especially lately at promoting its own developers. I guess we have at least 3 kinds of people here: A) Paid to do Git development, at least as part of their job. B) Freelancers who don't get paid directly for doing git but hope to profit from their git efforts directly or indirectly. C) Doing it in their freetime (or as minor, inofficial part of their non-programming job). I'm in camp C and honestly wasn't aware of camp B until now. I consider camp A to be beneficial for all of us, and I don't think specific employer interests have pushed the project in specific directions, or specific features (OK, maybe one, but not as a rule). I do see that remuneration is an issue for camp B. First thank you for responding to my email. It is great to see that some developers are interested in talking about this. I am in camp C and I think the people in all the camps are beneficial for all of us. Some facts: [...] I don't want to write again about each of these points now. I am more interested in discussing a good strategy to try to revert the sad trend of Git developers being promoted less and less, because I think that it is really very important. None of these facts is a big issue in itself for me, but I think the trend is very sad, and I would be happy if we could discuss here or at the Git Merge (or both) about ways to improve in this area. There should be a good occasion, after we see how it went, and hopefully also to sort out any apparent misunderstandings from the past that have resurfaced in this thread. Maybe, all we need is badges? [1] [1] https://badges.fedoraproject.org/ My opinion is that the big issue is that we should all realize how important it is to promote the Git developers. There are people who say out there that GitHub succeeded mostly because they easily allowed developers to build a portfolio. I think there is some truth in that. And I think GitHub also says to developers that it's good for them to have a nice GitHub portfolio and to employers that it's good for them to hire people who have a nice GitHub portfolio. This shows that the success of GitHub (and so of Git too) is based in part on promoting Open Source / Free Software developers. So why don't we try to do it more (instead of less) and how could we do it more (instead of less) for the Git developers? Yesterday evening I attended a Docker meeting in Paris [1] where Jérôme Petazzoni a Docker developer working for Docker gave a talk about Docker storage drivers. In the middle of his talk there were at least 2 slides dedicated to thank some developers who helped make Docker work with different filesystems or operating systems. And Jérôme did stop at least twice to thank these people in the middle of his talk. Wouldn't his talk have been smoother if he had not done that? So why did he do that? This reminded me about the following great talk by Julien Barbier the Community and Marketing guy at Docker: http://www.slideshare.net/julienbarbier42/community-marketing-42674728 I had seen this talk last december at another Docker meetup in Paris (and I think it really worth reading the slides or attending the talk if Julien gives it again and you can go). The slides and the talk keep repeating some sentences because they are worth repeating. Some of these sentences are: * It is about what you can do for your community * Belonging, recognition, respect, love * Add more links to your community * Your product is not what you say it is, it is what THEY say it is * It's all about people It is especially interesting to have a look at slide 5 where they say that Community is the new marketing and that Community is 80+% of their marketing. And it's true that they are really doing a lot for their community. For example the meeting yesterday evening was the 19th docker meeting in Paris in two years. And then there is slide 20 about Content Strategy where there is: * Encourage your community to build content - Say thank you, repost, post, upvote, RT, include them in your newsletter, itw them, … - Belonging, Recognition, Respect, Love * Your team is your community too! - Say thank you, gamify, hall of fame, tweet, post, recycle, etc… - Belonging, Recognition, Respect, Love So we can see that saying thank you is a big part of their content strategy. And are they successful? Yes, they are very successful as an open source project [2] and as a company. Now it's up to us, either we keep coming up with excuses not to promote developers, or we decide to do something about it. Best, Christian. [1]
Re: Promoting Git developers
Christian Couder christian.cou...@gmail.com writes: I don't want to write again about each of these points now. I am more interested in discussing a good strategy to try to revert the sad trend of Git developers being promoted less and less, because I think that it is really very important. I would suspect that those who agree with you would appreciate if you or somebody volunteered to act as our CKDO (chief kudos distribution officer). I do not think I have enough time to do that well. One good place to start might be to scan the list and summarize something like the following on weekly or monthly basis, as these are not something you can get by pointing people to git shortlog output. - Those who gave helpful review comments, how about going this way illustration patches, etc. Bonus points to those who helped onboarding newcomers. - Those who asked pertinent questions on common pain points, and those who answered them helpfully. If you are more ambitious, the source of the kudos may want to cover activities outside of this mailing list (e.g. giving talks and tutorials at conferences, etc.). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Wed, Mar 11, 2015 at 8:04 AM, Jason St. John jstj...@purdue.edu wrote: Or if that would make the release notes too cumbersome to review, what about using systemd's method? systemd's release notes include a contributions from section at the very end that lists everyone with a patch included in the release. Gnome projects do this too. They also separate translators from other contributions, but I don't think if we need to do that. I think the reason behind is translations go through the translator coordinator in gnome, who does the committing, so git shortlog does not really list translators. We may want to acknowledge review efforts as well, by grepping Helped-by:, Reviewed-by:... -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Jason St. John jstj...@purdue.edu writes: In the Git release notes for something like git foo learned a new option --bar, a simple (Thanks|Kudos) to John Smith at the end of each bullet point may be a good way to recognize developers in a concise manner without needing to dig through the output of git log or git shortlog. I doubt cluttering the list of features and fixes with peoples' names is such a good idea. Earlier we did not have any detailed release notes and instead said you can go read 'git log', which did not help the end users who need to know what changed before or after updating their Git, and I started doing the release notes in the current format to help them. We must not forget that the primary audience of this list of features and fixes is the end user. They need a brief birds-eye summary, and the briefer and the cleaner we keep it, the better. Besides, it will be a lot of work to dig log for topics and then go back to list archives to see who originally raised the issue before even the first edition of the patch was written and who contributed the ideas to help the author during the review cycles. Doing that for a topic that needed to get rerolled multiple times will take a lot of work, as the backlinks to previous round of discussions are often available only in human-readable form. And the list of people who helped will have to be updated when a follow-up bugfix topics are merged [*1*]. All of the above would add too much busywork on my plate [*2*]. Do people want to see me doing busywork, or spending that time on reviewing, suggesting improvements, rejecting crap and applying patches [*3*]? Or if that would make the release notes too cumbersome to review, what about using systemd's method? systemd's release notes include a contributions from section at the very end that lists everyone with a patch included in the release. I can add shortlog --no-merges -s -n v2.3.0..v2.4.0 at the end of the e-mail when the release notes is sent out. That might be a good enough balance between the usefulness of the release notes to its customers and giving credits to individuals in a way a bit more visible than if you are interested, run shortlog yourself [*4*]. Thanks. [Footnote] *1* Anybody remember Git traffic [*5*]? There was this great guy who have been summarizing the kernel traffic and soon after Git project started he did one edition of Git traffic, summarizing a few weeks' worth of Git mailing list discussions, who came up with what idea, how that idea was discarded, what decisions were made, in readble form. Unfortunately, there was only a single edition of Git traffic ever published---and I can understand why. During that inflation age of Git, we discussed so many topics and so much was achieved in a very short period of time. It would have been impossible for any single person to follow and report on all that was happening in the Git land, unless that person wasn't Linus or me or a handful of other people---but all of us were too busy with the discussion and programming to do a summary. I really wished the publication continued, but that was wishing for an impossible. If you want the point-by-point kudos, you do need somebody who can invest time to do a good job at this, and that person cannot be me or anybody who commits text to the release notes but an attentive and devoted reporter. An algorithm would not cut it. I suspect that a workflow improvement to help a dumb tool to automatically produce it would be too constricting and will slow me down. *2* What we need is a group of people who are interested in this enough to volunteer themselves to keep helping whatever kudo-giving that is needed in an ongoing basis. We do not need people who pile more on _my_ plate telling _me_ how to make the world better for them and then go away without doing anything themselves. We can find them dozen a dime and they won't help this project run any smoother. *3* Rhetorical question. I have long learned that the key to make sure the project runs smoothly is to push as much work off of my plate to make sure I won't become the bottleneck. *4* Note that it does not capture anything but these people did the final versions of the patches. We would not be giving credit to others who may have offered crucial insights to help these people. But that would give the same amount of rough estimate as the old contributors' list Christian misses from git-scm.com, and it might be good enough for somebody to see his name on it and feel good about it. *5* The site is gone, but wayback machine has a copy. https://web.archive.org/web/20050514083018/http://www.kerneltraffic.org/git/gt20050502_1.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Duy Nguyen pclo...@gmail.com writes: ... We may want to acknowledge review efforts as well, by grepping Helped-by:, Reviewed-by:... Agreed. Something along the lines of $ git shortlog --no-merges -s -n -t Helped-by -t Reviewed-by v2.3.0.. 6 4 0 Michael Haggerty 3 0 1 Jeff King 3 2 1 Junio C Hamano 1 0 0 Anders Kaseorg 1 0 0 Ben Walton 1 0 0 Jean-Noel Avila 1 0 0 Michael J Gruber 1 0 0 Michal Sojka 1 0 0 Mikko Rapeli 1 0 0 Mårten Kongstad 1 0 0 Nguyễn Thái Ngọc Duy 1 0 7 Stefan Beller that gives the number of trailer entries specified with -t in the order specified when doing the short/abbreviated form may be a good thing to have. The output can be piped to sort -k and cut to be cooked in any way. For completeness, in the long form, the extra numbers probably would come next to names of the individual: $ git shortlog --no-merges -n -t Helped-by -t Reviewed-by v2.3.0.. Michael Haggerty (6, 4, 0): write_ref_sha1(): remove check for lock == NULL write_ref_sha1(): move write elision test to callers lock_ref_sha1_basic(): do not set force_write for missing references reflog: improve and update documentation reflog_expire(): ignore --updateref for symbolic references reflog_expire(): never update a reference to null_sha1 Jeff King (3, 0, 1): gettext.c: move get_preferred_languages() from http.c diffcore-rename: split locate_rename_dst into two functions diffcore-rename: avoid processing duplicate destinations ... The long format needs to be careful not to drop those who helped others without any commit under their own names. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Tue, Mar 10, 2015 at 1:23 PM, Junio C Hamano gits...@pobox.com wrote: Christian Couder christian.cou...@gmail.com writes: I don't want to write again about each of these points now. I am more interested in discussing a good strategy to try to revert the sad trend of Git developers being promoted less and less, because I think that it is really very important. I would suspect that those who agree with you would appreciate if you or somebody volunteered to act as our CKDO (chief kudos distribution officer). I do not think I have enough time to do that well. One good place to start might be to scan the list and summarize something like the following on weekly or monthly basis, as these are not something you can get by pointing people to git shortlog output. - Those who gave helpful review comments, how about going this way illustration patches, etc. Bonus points to those who helped onboarding newcomers. - Those who asked pertinent questions on common pain points, and those who answered them helpfully. If you are more ambitious, the source of the kudos may want to cover activities outside of this mailing list (e.g. giving talks and tutorials at conferences, etc.). I don't know how feasible or desirable this would be, but I'll offer it anyway. In the Git release notes for something like git foo learned a new option --bar, a simple (Thanks|Kudos) to John Smith at the end of each bullet point may be a good way to recognize developers in a concise manner without needing to dig through the output of git log or git shortlog. Or if that would make the release notes too cumbersome to review, what about using systemd's method? systemd's release notes include a contributions from section at the very end that lists everyone with a patch included in the release. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Michael J Gruber g...@drmicha.warpmail.net writes: I guess we have at least 3 kinds of people here: A) Paid to do Git development, at least as part of their job. B) Freelancers who don't get paid directly for doing git but hope to profit from their git efforts directly or indirectly. C) Doing it in their freetime (or as minor, inofficial part of their non-programming job). I'm in camp C and honestly wasn't aware of camp B until now. I consider camp A to be beneficial for all of us, and I don't think specific employer interests have pushed the project in specific directions, or specific features (OK, maybe one, but not as a rule). I do see that remuneration is an issue for camp B. As one of the four things you are not supposed to talk about in a polite society, it is indeed hard to talk about money. Let me digress a bit before coming back to your 3 classes, because money is hard not only for those who want to receive, but is also hard for those who want to pay. I remember having a brief discussion during one of the GitTogether meetings with this person who managed Git users at his company. I think it was one of the chip makers whose association with Git was through its involvement with Android, but don't hold me to this, as I do not exactly remember. The conversation started with How do you get changes to Git? and what he ultimately wanted to learn was how a company can enhance Git to make the life of his engineers easier by hiring some Git experts and have them work on missing features. As you can guess, the conversation did not get to a satisfactory and clear here is how you would go about it. Sure, a company can pay a developer to do a feature, but it is impossible to predict if the end result will be used by us. For a usual work for hire, the hiring company can set the evaluation criteria itself, which would be that the end result works with the given version of the base software and produces desired result for the specific workflow the company needs. But the evaluation criteria for a contribution to us is not under the control of the paying company and the bar the person who does the work for hire has to cross is different. It of course needs to fill the needs of the sponsoring company, but also it needs to be cleanly done, maintainable, and it must not harm workflows other people employ, which the sponsoring company may not care about at all. That makes it hard for companies to pay a developer to work on Git to benefit themselves. It is the same deal for an enterprising soul who would start a crowdfunding campaign I'll add this feature to Git---if you guys raise this much money. This also makes the involvement of employers in category (A) a nuanced one. Because money is not an effective currency to buy inclusion, Paid to do Git development does not equate Companies pay developers to develop Git in a way to benefit the sponsoring companies. When it comes to working on Git, I, Shawn or Jonathan do not get orders from Google management to add funky features nobody outside Google would use to help Android [*1*], and I doubt that Peff and Michael's job description are to push GitHub specific enhancement into our codebase, either [*2*]. There are different schools of thought on how to support open source development [*3*]. I heard some people dream of free software tax and have public support our endeavor, just like public purse supports academia. We do not live in such world. Some projects pay for bugs with bounty program; I think that would be the closest thing to support your category (B), and that form of support does not have to be limited to bugs. Projects could buy features in addition to bugs. But we are not structured that way, at least so far. If we start to buy features, that would make it even more difficult than the My company wants to fund somebody to add features to Git---how do we go about it? case. How do we decide an effort was successful? Would that decision be affected by the fact that we paid for it in the first place (i.e. declaring a failure would mean we admit that we made a mistake when approving to fund the effort)? When other developers think that a feature we bought shouldn't have been bought in the first place, what happens? How should conflicts in such decisions be resolved? How would that payment affect people who are in category (C), or category (A) for that matter? Faced with two reasonable implementations by a bounty hunter and a hobbyist, does it enter the equation that one costs and the other is free? Do we pay everybody to sidestep that issue? Where does the money come from? Do we want to become a project that employ some developers but not others? Who makes hiring decision and how? In short, I agree with you that we are not set up to support bounty hunters very well. That might be something we want to change, but I am not sure what the endgame would be, if I would like that endgame when I see it, or what the first step to reach that endgame would
Re: Promoting Git developers (was: Bashing freelancers)
Christian Couder venit, vidit, dixit 07.03.2015 08:18: Hi, On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup d...@gnu.org wrote: At some point of time I think it may be worth reevaluating the toxic atmosphere against freelancers doing Git development. My opinion on this is that the Git community has not been good especially lately at promoting its own developers. I guess we have at least 3 kinds of people here: A) Paid to do Git development, at least as part of their job. B) Freelancers who don't get paid directly for doing git but hope to profit from their git efforts directly or indirectly. C) Doing it in their freetime (or as minor, inofficial part of their non-programming job). I'm in camp C and honestly wasn't aware of camp B until now. I consider camp A to be beneficial for all of us, and I don't think specific employer interests have pushed the project in specific directions, or specific features (OK, maybe one, but not as a rule). I do see that remuneration is an issue for camp B. Some facts: * There used to be an AUTHORS section in each of the git man page. They have been removed. The rational was that they were hard to maintain and the information about authors was easily available elsewhere. I'd say it's difficult to do this in a fair manner, since most pages are a community effort now in the best sense. * There used to be a nice page on git-scm.com, the main Git web site, listing the authors and how many commits they had contributed. It has been removed. It was out of date again and again, and pull-requests took forever. The problem here still seems to be the old dis-connectedness between that website and the developers' community. But it's the only one we have. Since we're talking business: git-scm.com still looks a bit like a ProGit/Github promotion site. I don't have anything against either, and git-scm.com provides a lot of the information that users are looking for, and that are hard to find anywhere else; it's a landing page. It just does not look like a project home. * In the A note from the maintainer emails that Junio regularly sends, the last section about Other people's trees, trusted lieutenants and credits. seems to have been truncated for some time and doesn't show anymore the nice credits words it used to show. Maybe this is a bug. Being in camp C, that entry in credits was my remuneration, so-to-say, and I missed it when it was gone. OTOH, I do understand how tedious it is to keep that up to date and fair. (And if, I should probably have been removed at some point...) There still is git rev-list --count --author=Mickey origin/master :) * https://www.openhub.net/p/git/contributors/summary seems to give me a 504 Gateway Time-out right now :-( I thought there is ohloh, but that one is the new ohloh... Anyways, Junio's repo on github is official in a sense and has this: https://github.com/git/git/graphs/contributors * On the Git Merge web site, we can see that none of the speakers seems to have been a very active contributor to git.git Yeah, that's more an outside business window into git. In fact, while that doesn't quite intrigue me, I would think it's a great chance for freelancers to get in touch with people doing business with git. And maybe they'll be talking about what they're using git for, and which technical and non-technical challenges they meet in doing so? Edward was fun to listen to in Berlin :) Git merge itself is organized and sponsored by businesses with business interests. But there's also the contributors summit. Git merge Berlin was great and generous in that respect. None of these facts is a big issue in itself for me, but I think the trend is very sad, and I would be happy if we could discuss here or at the Git Merge (or both) about ways to improve in this area. There should be a good occasion, after we see how it went, and hopefully also to sort out any apparent misunderstandings from the past that have resurfaced in this thread. Maybe, all we need is badges? [1] Michael [1] https://badges.fedoraproject.org/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
Michael J Gruber g...@drmicha.warpmail.net writes: Christian Couder venit, vidit, dixit 07.03.2015 08:18: Hi, On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup d...@gnu.org wrote: At some point of time I think it may be worth reevaluating the toxic atmosphere against freelancers doing Git development. My opinion on this is that the Git community has not been good especially lately at promoting its own developers. I guess we have at least 3 kinds of people here: A) Paid to do Git development, at least as part of their job. B) Freelancers who don't get paid directly for doing git but hope to profit from their git efforts directly or indirectly. C) Doing it in their freetime (or as minor, inofficial part of their non-programming job). I'm in camp C and honestly wasn't aware of camp B until now. My guess is that camp B is dead and intentionally so. For the rationale, see for example URL:http://article.gmane.org/gmane.comp.version-control.git/247165/. It is considered tasteless to even mention camp B. -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
From: David Kastrup d...@gnu.org Michael J Gruber g...@drmicha.warpmail.net writes: Christian Couder venit, vidit, dixit 07.03.2015 08:18: Hi, On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup d...@gnu.org wrote: At some point of time I think it may be worth reevaluating the toxic atmosphere against freelancers doing Git development. My opinion on this is that the Git community has not been good especially lately at promoting its own developers. I guess we have at least 3 kinds of people here: A) Paid to do Git development, at least as part of their job. B) Freelancers who don't get paid directly for doing git but hope to profit from their git efforts directly or indirectly. C) Doing it in their freetime (or as minor, inofficial part of their non-programming job). I'm in camp C and honestly wasn't aware of camp B until now. My guess is that camp B is dead and intentionally so. For the rationale, see for example URL:http://article.gmane.org/gmane.comp.version-control.git/247165/. It is considered tasteless to even mention camp B. There seems to be some talking past each other going on. A common problem [1] is that the apparent middle ground B is actually split two ways, (because A and C are not opposites but embed different ethos) There maybe those B's who are well paid independent programmers, who are able to choose how to use their spare time in the same manner as those in C. And there are those who, like some of the As , need some payment to use their hours to the benefit of Git. This will be particularly true of those who are not well remunerated from their independent work. If they are giving up precious work time then they would at least hope for a little acknowledgment. To me it sounds as if Junio is thinking more of the former while David is thinking of the latter. These misunderstandings are difficult to resolve, or at least reconcile, without a proper understanding of the root causes of the differences. -- Philip [1] This common problem is summarised in the Competing Values Framework (CVF), which is usually applied to management philosophies, but is a common styling in many disputes and misunderstandings. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html