{"thread":{"id":"41269","subject":"Starting on a microproject for GSoC","startedAt":"2016-01-28T00:40:32Z","lastAt":"2016-01-28T19:45:07Z","messageCount":7,"participants":["Moritz Neeb","Stefan Beller","Andrew Ardill","Johannes Schindelin","Lars Schneider","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"276935","messageId":"56A96380.3020308@moritzneeb.de","threadId":"41269","inReplyTo":null,"subject":"Starting on a microproject for GSoC","fromName":"Moritz Neeb","fromEmail":"lists@moritzneeb.de","sentAt":"2016-01-28T00:40:32Z","receivedAt":"2016-01-28T00:40:32Z","isPatch":false,"sender":{"key":"lists@moritzneeb.de","avatar":null},"body":"Hi git developers,\n\nthe next Google Summer of Code is not too far away. I expect git to\napply for it and hopefully have some student spots which in turn I plan\nto apply. It was recommended elsewhere and on this list as well, that it\nis beneficial to engage with the community early, that's why I am\nwriting to you already now, before all this formal stuff has begun.\n\nBefore I may introduce myself: I'm a Computer Science student in\nGermany, coming towards the end of my Masters. I am an enthusiastic git\nuser that's why I'd like to give something back. This would be my first\ntime to actually contribute to a FOSS project and I am quite excited\n(also a bit frightened ;)).\n\nAs the list of available microprojects 2016 is still to be created, I\nmight need your help in finding a project to work on. I started to dig\nthrough the archives along items of the list of 2015 [0] and so far\nfound out the following:\n\nThe first task, to make \"git -C '' cmd\" not to barf seems to be solved.\nI tried it with \"git -C '' status\" at least. I could not find the\nrelated patch, maybe it did use other keywords. I would be interested.\n\nThe second task, to allow \"-\" as a short-hand for \"@{-1}\" in more places\nseems to be still open for reset, although someone almost finished it\n(cf. $gmane/265417). I suppose just fixing/revising this would be kind\nof a too low hanging fruit? More interesting (also because I am a bit\nearlier) might be to unify everything, as suggested by Junio in\n$gmane/265260. Or implementing it for another branch command, e.g. rebase.\n\nThe other tasks I did not yet dig into.\n\nIf all of that is considered as not relevant, I might just go for a\nnewer idea, like converting strbuf_getline_lf() callers to\nstrbuf_getline(), as suggested in $gmane/284104.\n\nAny thoughts?\n\nA question regarding the process of \"taking a task (or bug)\" in general:\nIs it solely organized through the mailing list? Suppose I start to work\non something, should I announce it to not risk work duplication? Does it\nhappen often that more people accidentally work on the same task?\n\nBest,\nMoritz\n\n[0] http://git.github.io/SoC-2015-Microprojects.html\n"},{"id":"276942","messageId":"CAGZ79kbKe8C6iDtRNXgNU4-8EAvgE4RvxVvi-Xzg5Tf++m7z3Q@mail.gmail.com","threadId":"41269","inReplyTo":"56A96380.3020308@moritzneeb.de","subject":"Re: Starting on a microproject for GSoC","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-01-28T01:18:39Z","receivedAt":"2016-01-28T01:18:39Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Jan 27, 2016 at 4:40 PM, Moritz Neeb <lists@moritzneeb.de> wrote:\n> Hi git developers,\n>\n> the next Google Summer of Code is not too far away. I expect git to\n> apply for it and hopefully have some student spots which in turn I plan\n> to apply. It was recommended elsewhere and on this list as well, that it\n> is beneficial to engage with the community early, that's why I am\n> writing to you already now, before all this formal stuff has begun.\n>\n> Before I may introduce myself: I'm a Computer Science student in\n> Germany, coming towards the end of my Masters. I am an enthusiastic git\n> user that's why I'd like to give something back.\n\nGiving back is a noble thing. To have most fun at it, you need to ask yourself:\nWhat is the most obnoxious part of Git that you personally use? What was\nthe latest problem you had, which you'd want to fix? If you identified\nthat, is that the right size to fix it? (Usually it is way bigger than thought,\nbut you can ask around if there are approaches for solving that problem ;)\n\n> This would be my first\n> time to actually contribute to a FOSS project and I am quite excited\n> (also a bit frightened ;)).\n\nEach FLOSS project is run differently. So in case your fright\nwas the right instinct, go for some other project, it will be totally different.\n\n>\n> As the list of available microprojects 2016 is still to be created, I\n> might need your help in finding a project to work on. I started to dig\n> through the archives along items of the list of 2015 [0] and so far\n> found out the following:\n\nSome smaller starter projects may be found at\nhttp://git-blame.blogspot.com/p/leftover-bits.html\nThe size and difficulty of these projects may vary\na bit more than the micro projects for GSoC though.\n\n>\n> The first task, to make \"git -C '' cmd\" not to barf seems to be solved.\n> I tried it with \"git -C '' status\" at least. I could not find the\n> related patch, maybe it did use other keywords. I would be interested.\n>\n> The second task, to allow \"-\" as a short-hand for \"@{-1}\" in more places\n> seems to be still open for reset, although someone almost finished it\n> (cf. $gmane/265417). I suppose just fixing/revising this would be kind\n> of a too low hanging fruit? More interesting (also because I am a bit\n> earlier) might be to unify everything, as suggested by Junio in\n> $gmane/265260. Or implementing it for another branch command, e.g. rebase.\n>\n> The other tasks I did not yet dig into.\n>\n> If all of that is considered as not relevant, I might just go for a\n> newer idea, like converting strbuf_getline_lf() callers to\n> strbuf_getline(), as suggested in $gmane/284104.\n>\n> Any thoughts?\n>\n> A question regarding the process of \"taking a task (or bug)\" in general:\n> Is it solely organized through the mailing list?\n\nYes, I'd say 95% of the discussion is done on the mailing list.\n(The remaining 5% is done on conferences,\nor privately for security related stuff I'd assume)\n\n> Suppose I start to work\n> on something, should I announce it to not risk work duplication?\n\n[In the context of fighting procrastination,] I recently read that announcing\nthat you are going to work on $FOO is not necessarily helpful\nfor actually doing it. Chances are lower that you actually finish a\nthing which you announced.\n\nHowever feel free to announce what you work on. Usually people don't.\n\n> Does it\n> happen often that more people accidentally work on the same task?\n\nIt happens rarely for larger goals. For the GSoc micro projects however\nsome students did the same thing with slight differences. (2015 we only\nhad 2 spots to fill but a few more applicants (3-5?), but seeing\nhow students approached the same problem helped on deciding whom\nto mentor. (Given different problems it would have been harder.)\n\n>\n> Best,\n> Moritz\n>\n> [0] http://git.github.io/SoC-2015-Microprojects.html\n\nI just realized there are some micro projects on the 2014 page\nas well which haven't been solved yet. (maybe, they are not\nstriked through)\n\nThanks,\nStefan\n"},{"id":"276956","messageId":"CAH5451=u1MB=LJyBv+Z9e4Y5ncHktMw+oEycOWV1YXASaawMDA@mail.gmail.com","threadId":"41269","inReplyTo":"56A96380.3020308@moritzneeb.de","subject":"Re: Starting on a microproject for GSoC","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2016-01-28T06:17:15Z","receivedAt":"2016-01-28T06:17:15Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 28 January 2016 at 11:40, Moritz Neeb <lists@moritzneeb.de> wrote:\n> I suppose just fixing/revising this would be kind\n> of a too low hanging fruit?\n\nI am in no way qualified to speak to the majority of your post, but I\ncan't imagine anyone refusing your work because it was 'too low\nhanging fruit'.\n\nIndeed, the general gist of getting people to start with a\nmicroproject has always appeared to help potential applicants\nunderstand what it takes to get a patch accepted in git. As long as\nthe low hanging fruit is useful (your example of polishing a patchset\nto get it into master is definitely useful, assuming the patchset is\nuseful) then I'd say go for it.\n\nIn the worst case, if you feel your contribution was not 'meaty'\nenough, there is nothing to stop you working on some other problem, or\nextending the first further. That said, I do remember previous\napplicants trying to do as many microprojects as possible, leaving few\nfor other people.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"276964","messageId":"alpine.DEB.2.20.1601280919240.2964@virtualbox","threadId":"41269","inReplyTo":"CAH5451=u1MB=LJyBv+Z9e4Y5ncHktMw+oEycOWV1YXASaawMDA@mail.gmail.com","subject":"Re: Starting on a microproject for GSoC","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-01-28T08:22:40Z","receivedAt":"2016-01-28T08:22:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Moritz & Andrew,\n\nOn Thu, 28 Jan 2016, Andrew Ardill wrote:\n\n> On 28 January 2016 at 11:40, Moritz Neeb <lists@moritzneeb.de> wrote:\n> > I suppose just fixing/revising this would be kind\n> > of a too low hanging fruit?\n> \n> I am in no way qualified to speak to the majority of your post, but I\n> can't imagine anyone refusing your work because it was 'too low\n> hanging fruit'.\n\nI would agree that it is *not* a \"too low hanging fruit\".\n\nThe thing is, it would be a really easy way to get into the groove, to\nunderstand how changes are expected to be contributed, what the process of\niterating the patches/patch series is, and in what form the patches are\npreferred.\n\nMoritz, if you worry about this lil' project to be too little, why don't\nyou just start with it and then tackle another one? That way, you will be\nalready very familiar with the Git project (and the regulars will be\nfamiliar with you) when GSoC comes around.\n\nCiao,\nJohannes\n"},{"id":"276967","messageId":"1FEDCA48-FE77-44C3-8C4A-65B4C435E6B3@gmail.com","threadId":"41269","inReplyTo":"56A96380.3020308@moritzneeb.de","subject":"Re: Starting on a microproject for GSoC","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-01-28T08:51:48Z","receivedAt":"2016-01-28T08:51:48Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 28 Jan 2016, at 01:40, Moritz Neeb <lists@moritzneeb.de> wrote:\n\n> As the list of available microprojects 2016 is still to be created, I\n> might need your help in finding a project to work on.\n\nAs Stefan already pointed out, working on something that scratches your (Git) itch is probably the best way to find a project.\nMy recent itch was that I broke a test on Linux which I did not realize as I primarily work on OSX. As a solution for myself I suggested a TravisCI patch to the mailing list and it was accepted:\nhttps://travis-ci.org/git/git/branches \n\nI see a number of ways to improve the Git TravisCI integration:\n\n* install CVS on the build machines to run t94?? and t96?? tests\n* install SVN on the build machines to run t91?? tests\n* install Apache Web Server to run 5539, 5550, and 5561\n* investigate if it is possible to run t1509 root worktree test\n* investigate if it is possible to add jgit to run t5310\n* investigate why GIT_TEST_LONG=YesPlease does not work on TravisCI\n* investigate if we can use pylint to analyze the git-p4 Python code\n* investigate if we can trigger Coverity static code analysis for the Git master\n  branch (hint: Stefan Beller already looked into this)\n  https://scan.coverity.com/travis_ci\n\nI think all of these tasks can be done without deep Git knowledge. However, working with the tests is quite a good way to learn more about a complex project like Git.\n\nCheers,\nLars"},{"id":"276981","messageId":"56A9EF68.5020803@moritzneeb.de","threadId":"41269","inReplyTo":"CAGZ79kbKe8C6iDtRNXgNU4-8EAvgE4RvxVvi-Xzg5Tf++m7z3Q@mail.gmail.com","subject":"Re: Starting on a microproject for GSoC","fromName":"Moritz Neeb","fromEmail":"lists@moritzneeb.de","sentAt":"2016-01-28T10:37:28Z","receivedAt":"2016-01-28T10:37:28Z","isPatch":false,"sender":{"key":"lists@moritzneeb.de","avatar":null},"body":"On 01/28/2016 02:18 AM, Stefan Beller wrote:\n> On Wed, Jan 27, 2016 at 4:40 PM, Moritz Neeb <lists@moritzneeb.de> wrote:\n>> Before I may introduce myself: I'm a Computer Science student in\n>> Germany, coming towards the end of my Masters. I am an enthusiastic git\n>> user that's why I'd like to give something back.\n> \n> Giving back is a noble thing. To have most fun at it, you need to ask yourself:\n> What is the most obnoxious part of Git that you personally use? What was\n> the latest problem you had, which you'd want to fix? If you identified\n> that, is that the right size to fix it? (Usually it is way bigger than thought,\n> but you can ask around if there are approaches for solving that problem ;)\n\nYou're right, creating something that is in the end relevant and useful\nfor myself is even more fun. I have some itches, I will work on\nspecifying them. I have the feeling though, that for solving the daily\nissues and itches it's not necessary to dig into the core of git.\n\nFor example, I sometimes create a commit with the wrong email address (I\ntry to separate between work/private stuff) and that annoys me. I think\nthis could be solved by some hook rather than modifying git itself.\n\n> I just realized there are some micro projects on the 2014 page\n> as well which haven't been solved yet. (maybe, they are not\n> striked through)\n\nYeah, I realized too that there are some points not striked through in\n[0]. Might be just not up to date, for example number 15. seems to be\nsolved ($gmane//244020). Looking into the code, 14. is solved as well.\nFor 17. there could be something left.\n\nThanks,\nMoritz\n\n[0] http://git.github.io/SoC-2014-Microprojects.html\n"},{"id":"276999","messageId":"xmqqio2dij3w.fsf@junio.mtv.corp.google.com","threadId":"41269","inReplyTo":"56A96380.3020308@moritzneeb.de","subject":"Re: Starting on a microproject for GSoC","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-28T19:45:07Z","receivedAt":"2016-01-28T19:45:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Moritz Neeb <lists@moritzneeb.de> writes:\n\n> the next Google Summer of Code is not too far away. I expect git to\n> apply for it and hopefully have some student spots which in turn I plan\n> to apply. It was recommended elsewhere and on this list as well, that it\n> is beneficial to engage with the community early, that's why I am\n> writing to you already now, before all this formal stuff has begun.\n\nIt is unknown if we are going to participate in GSoC this year.  One\nquestion you must ask yourself first: will you still be interested\nin hacking Git if we decide not to take GSoC students this year?\n\nThe GSoC microprojects are not about seeing who writes great code.\nWhat we want to see primarily with them is how well candidates\ninteract with the community, responding to reviewers, showing\nagreement or disagreement with received comments, making arguments\nin a constructive way when opinions differ, updating their\nsubmissions with suggested improvements in a timely matter to keep\nthe ball rolling, etc.  GSoC micros are primarily designed to be\nsmall and can be finished within a short timeframe, but expected to\nstill have enough iterations with reviewers that candidates can use\nas an opportunity to demonstrate how well they can work with the\ncommunity.\n\nSuppose a candidate already tackled a micro, went through multiple\niterations with reviewers and came up with a polished solution.\nWhen another candidate comes late and sends in a very similar\n\"answer\" to the same micro, without meaningful interactions with the\nreviewers and the community, the latter candidate would not be\ndemonstrating how good a \"fit\" s/he is in the community at all.\n\nOn the other hand, if the latter candidate approaches the same micro\nsomebody else attacked in a different way, s/he would have his or\nher own interactions with the reviewers and would be demonstrating\nhis or her ability to work with us.\n\nSo in that sense, they are not \"quiz\" that has a single right\nanswer, and we do not necessarily have problems if multiple\ncandidates attack the same micro.\n\nNow, if your answer to the \"first\" question is \"No\", then you might\nwant to avoid wasting your effort investing too early in preparing\nfor an event that may not happen.  You may want to stop reading here\nand wait until GSoC micros are posted (if we decide to participate\nthis year, that is).\n\nIf the answer is \"Yes\", then welcome to the Git development\ncommunity ;-)\n\nThe purpose of GSoC micro I explained above also means that people\nlike you, who are interested in hacking Git, can start early and do\ntheir own things to demonstrate that they can work well with our\ncommunity, which may give them a head start.  When they apply to be\na GSoC student (if we participate this year), we would already have\nenough datapoint to convince ourselves that it would be a good idea\nto pick them (even without them doing GSoC micro).\n\n> The second task, to allow \"-\" as a short-hand for \"@{-1}\" in more\n> places seems to be still open for reset, although someone almost\n> finished it (cf. $gmane/265417). I suppose just fixing/revising\n> this would be kind of a too low hanging fruit?  More interesting\n> (also because I am a bit earlier) might be to unify everything, as\n> suggested by Junio in $gmane/265260. Or implementing it for\n> another branch command, e.g. rebase.\n\nThis actually is a very tricky one to do well.\n\n> If all of that is considered as not relevant, I might just go for\n> a newer idea, like converting strbuf_getline_lf() callers to\n> strbuf_getline(), as suggested in $gmane/284104.\n\nIt is a good sign that you are familiar with a recent list\ndiscussion.  There are other \"once this topic settles, we would\nprobably want to do this and that kind of cleanups on top\" left\nbehind that haven't made my \"leftover bits\" page (which I update\nonly after the discussion dies on the list and there is no sign that\nothers will be picking them up soonish).\n\nHave fun.\n"}]}