{"thread":{"id":"32927","subject":"Google Summer of Code 2013 (GSoC13)","startedAt":"2013-02-18T17:23:01Z","lastAt":"2013-02-26T04:59:54Z","messageCount":47,"participants":["Thomas Rast","Jeff King","Ramkumar Ramachandra","Ronan Keryell","Jonathan Nieder","Jens Lehmann","Junio C Hamano","Duy Nguyen","Christian Couder","Shawn Pearce","Matthieu Moy","Michael Schubert","Carlos Martín Nieto","Florian Achleitner","Jaseem Abid"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"209689","messageId":"87ehgd1qq2.fsf@pctrast.inf.ethz.ch","threadId":"32927","inReplyTo":null,"subject":"Google Summer of Code 2013 (GSoC13)","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-02-18T17:23:01Z","receivedAt":"2013-02-18T17:23:01Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Hi,\n\nGoogle announced the 2013 incarnation of the Google Summer of Code\nprogram on Feb 11:\n\n http://www.google-melange.com/gsoc/homepage/google/gsoc2013\n\nGit has taken part in previous years, so I figure somebody should get\nthe ball rolling again! The following items need to be sorted out:\n\n* We need an org admin. AFAIK this was done by Peff and Shawn in\n tandem last year. Would you do it again?\n\n* We should prepare an \"ideas page\". Last year, Peff made one on\n\n https://github.com/peff/git/wiki/SoC-2012-Ideas\n\n I couldn't edit it there over git access[1], so I made a clone in \"my\"\n github wiki:\n\n https://github.com/trast/git/wiki/SoC-2013-Ideas\n\n I'll volunteer to manage that wiki[2]. Please either edit it\n directly, or send me patches or pull requests. I won't really have\n time to properly review them, but I'll do my best to merge everything.\n\n* Naturally that ideas page is a bit stale now, and three projects\n shorter. Please propose new ideas and refresh or delete the old ones!\n In particular some projects spawned long discussions on the list, and\n the results of those discussions should be integrated to avoid deja\n vus.\n\n* We should have a pool of mentors and rough mentor-project matchings.\n I gathered a -- certainly incomplete -- list of previous mentors and\n students in the Cc field; maybe some of you are interested again? If\n so, propose your own ideas and/or list yourself in the \"proposed\n mentors\" for some existing projects. (I cleared all those fields for\n now.)\n\n* Even if you don't want to mentor, you can still contribute by helping\n with discussing and ranking proposals, especially immediately before\n and after the project submission deadline (May 3).\n\nIf we want to participate again, we need to get together an org\napplication until *March 29* 19:00 UTC, and it won't exactly hurt to\nhave the ideas page settled until then too.\n\nIt would be really nice if we could do this again, I think GSoC is a\ngreat opportunity both for Git and the involved students.\n\nCheers\nThomas\n\n\nFootnotes: \n[1] That's a bit silly really, since I *can* edit it via the web\ninterface. Peff, perhaps you can get that fixed?\n\n[2] Unless Peff wants to take it over again? You could just pull it\nfrom the git version, it's based on your history.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"209690","messageId":"20130218174239.GB22832@sigill.intra.peff.net","threadId":"32927","inReplyTo":"87ehgd1qq2.fsf@pctrast.inf.ethz.ch","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-18T17:42:39Z","receivedAt":"2013-02-18T17:42:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote:\n\n> * We need an org admin. AFAIK this was done by Peff and Shawn in\n> tandem last year. Would you do it again?\n\nI will do it again, if people feel strongly about Git being a part of\nit. However, I have gotten a little soured on the GSoC experience. Not\nbecause of anything Google has done; it's a good idea, and I think they\ndo a fine of administering the program. But I have noticed that the work\nthat comes out of GSoC the last few years has quite often not been\nmerged, or not made a big impact in the codebase, and nor have the\nparticipants necessarily stuck around.\n\nAnd I do not want to blame the students here (some of whom are on the cc\nlist :) ). They are certainly under no obligation to stick around after\nGSoC ends, and I know they have many demands on their time. But I am\nalso thinking about what Git wants to get out of GSoC (and to my mind,\nthe most important thing is contributors).\n\nAs far as merged code, I think part of the problem is that git is fairly\nmature at this point. The most interesting projects are of a bigger\nscope than a student with no experience in the code base can do in a\nsummer project. Maybe that means we need to do a better job of breaking\nprojects down into reasonably sized sub-components. Or maybe it means\nthe project is hitting a point of diminishing returns for GSoC. I don't\nknow.\n\nThere are a few counterpoints I can think of:\n\n - Even though not all projects are winners, _some_ are. I see Carlos\n and Ram on the cc list, two people who started as GSoC students and\n stuck around.\n\n - There is also the angle that even if _Git_ doesn't benefit directly\n from people sticking around, those people may float into other open\n source projects and work on them. Which makes the world a better\n place on the whole.\n\nSo I don't know. Those are just some things that have been floating\naround in my head. Feel free to ignore or discuss.\n\nBut thanks for getting the ball rolling, Thomas. If we are going to do\nit, sooner is better, and if we aren't, then we should probably do so\nconsciously, and not just miss the deadline accidentally. :)\n\n> * We should prepare an \"ideas page\". Last year, Peff made one on\n> \n> https://github.com/peff/git/wiki/SoC-2012-Ideas\n> \n> I couldn't edit it there over git access[1], so I made a clone in \"my\"\n> github wiki:\n> [...]\n> [1] That's a bit silly really, since I *can* edit it via the web\n> interface. Peff, perhaps you can get that fixed?\n\nUgh, I would have to write ruby code to fix that. I'll try to trick\nsomebody else here into fixing it. :)\n\n> [2] Unless Peff wants to take it over again? You could just pull it\n> from the git version, it's based on your history.\n\nI think it is as good on your repo as on mine. The kernel.org wiki is\nalso up, and the github/peff/git one was supposed to be temporary. But I\nreally hate any wiki that I cannot edit with vim. I guess we need to\nhave a discussion as a group about where the \"official\" wiki should\nlive, and it should go there (I can also put it at github/git/git, which\nis a more sane place; but I do not want to compete with kernel.org's\nwiki unless there is community consensus that we are moving).\n\n-Peff\n"},{"id":"209691","messageId":"87k3q5zfaa.fsf@pctrast.inf.ethz.ch","threadId":"32927","inReplyTo":"87ehgd1qq2.fsf@pctrast.inf.ethz.ch","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2013-02-18T17:46:05Z","receivedAt":"2013-02-18T17:46:05Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Thomas Rast writes:\n\n> * We should prepare an \"ideas page\"[...]\n> https://github.com/trast/git/wiki/SoC-2013-Ideas\n\n>From where I'm currently sitting, I won't have the time to mentor this\nyear. So my two earlier proposals are essentially up for grabs:\n\n1. Improving parallelism in various commands\n -----------------------------------------\n \n Git is mostly written single-threaded, with a few commands having\n bolted-on extensions to support parallel operation (notably git-grep,\n git-pack-objects and the core.preloadIndex feature).\n \n We have recently looked into some of these areas and made a few\n optimizations, but a big roadblock is that pack access is entirely\n single-threaded. The project would consist of the following steps:\n \n * In preparation (the half-step): identify commands that could\n benefit from parallelism. `git grep --cached` and `git grep\n COMMIT` come to mind, but most likely also `git diff` and `git log\n -p`. You can probably find more.\n \n * Rework the pack access mechanisms to allow the maximum possible\n parallel access.\n \n * Rework the commands found in the first step to use parallel pack\n access if possible. Along the way, document the improvements with\n performance tests.\n \n The actual programming must be done in C using pthreads for obvious\n reasons. At the very least you should not be scared of low-level\n programming. Prior experience and access to one or more multi-core\n computers is a plus.\n\nThis one is probably still a contender. However, it might be worth\nfirst looking into whether using libgit2 for pack reading would be\neasier and faster, since it is written to be reentrant from the ground\nup.\n\n\n2. Improving the `git add -p` interface\n ------------------------------------\n\n The interface behind `git {add|commit|stash|reset} {-p|-i}` is shared\n and called `git-add--interactive.perl`. This project would mostly\n focus on the `--patch` side, as that seems to be much more widely\n used; however, improvements to `--interactive` would probably also be\n welcome.\n\n The `--patch` interface suffers from some design flaws caused largely\n by how the script grew:\n\n * Application is not atomic: hitting Ctrl-C midway through patching\n may still touch files.\n\n * The terminal/line-based interface becomes a problem if diff hunks\n are too long to fit in your terminal.\n\n * Cannot go back and forth between files.\n\n * Cannot reverse the direction of the patch.\n\n * Cannot look at the diff in word-diff mode (and apply it normally).\n\n Due to the current design it is also pretty hard to add these features\n without adding to the mess. Thus the project consists of:\n\n * Come up with more ideas for features/improvements and discuss them\n with users.\n\n * Cleanly redesigning the main interface loop to allow for the above\n features.\n\n * Implement the new features.\n\n As the existing code is written in Perl, that is what you will use for\n this project.\n\nThis has already featured twice, and resulted in proposals that were\ninsufficiently advanced and too little work for a GSoC. If nobody feels\nlike extending it to a bigger project, I'll just scrap it.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"209693","messageId":"87fw0ta4ai.fsf@an-dro.info.enstb.org","threadId":"32927","inReplyTo":"87k3q5zfaa.fsf@pctrast.inf.ethz.ch","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Ronan Keryell","fromEmail":"ronan.keryell@silkan.com","sentAt":"2013-02-18T18:02:45Z","receivedAt":"2013-02-18T18:02:45Z","isPatch":false,"sender":{"key":"ronan.keryell@silkan.com","avatar":null},"body":">>>>> On Mon, 18 Feb 2013 18:46:05 +0100, Thomas Rast said:\n\n Thomas> The actual programming must be done in C using pthreads\n Thomas> for obvious reasons.\n\nAre there obvious reasons OpenMP would not be enough to do the job?\n\nIt looks like a trade-off between the code readability & portability\nversus the real expressiveness of what parallelism control details are\nneeded.\n-- \n Ronan KERYELL |\\/ Phone: +1 650 386 6482\n SILKAN Wild Systems |/)\n 4962 El Camino Real #201 K Ronan.Keryell@silkan.com\n Los Altos, CA 94022 |\\ skype:keryell\n USA | \\ http://silkan.com\n"},{"id":"209692","messageId":"CALkWK0ne3GX7wA1U0-TnMqU3mTFNe12TQ_s0=2MVJ=BMs8tirA@mail.gmail.com","threadId":"32927","inReplyTo":"87k3q5zfaa.fsf@pctrast.inf.ethz.ch","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-18T18:13:01Z","receivedAt":"2013-02-18T18:13:01Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Thomas Rast wrote:\n> 2. Improving the `git add -p` interface\n> ------------------------------------\n\n> * The terminal/line-based interface becomes a problem if diff hunks\n> are too long to fit in your terminal.\n\nI don't know if it's worth coming up with another interface. The best\nsolution for this is editor integration, in my opinion. I use Magit\nmostly for just the graphical staging/ unstaging. There's also a\nFugitive.vim for vim.\n\n> * Cannot look at the diff in word-diff mode (and apply it normally).\n\nYes, this is a major limitation that would be nice to fix.\nAlso: Having to figure out, heuristically, when to actually turn it on\nmight be a worthwhile feature, especially for services like GitHub.\n\n> As the existing code is written in Perl, that is what you will use for\n> this project.\n\nI don't know- is Perl a possible deterrent?\nWon't getting a word-diff to apply involve C work though? (patching\nbuiltin/apply.c?)\n"},{"id":"209698","messageId":"CALkWK0nDEwgDwnVktmM8abv3ZgQmJCOm8LBe25UKR485PZMPfA@mail.gmail.com","threadId":"32927","inReplyTo":"20130218174239.GB22832@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-18T18:44:19Z","receivedAt":"2013-02-18T18:44:19Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"[corrected David Barr's email address]\n\nJeff King wrote:\n> And I do not want to blame the students here (some of whom are on the cc\n> list :) ). They are certainly under no obligation to stick around after\n> GSoC ends, and I know they have many demands on their time. But I am\n> also thinking about what Git wants to get out of GSoC (and to my mind,\n> the most important thing is contributors).\n>\n> As far as merged code, I think part of the problem is that git is fairly\n> mature at this point. The most interesting projects are of a bigger\n> scope than a student with no experience in the code base can do in a\n> summer project. Maybe that means we need to do a better job of breaking\n> projects down into reasonably sized sub-components. Or maybe it means\n> the project is hitting a point of diminishing returns for GSoC. I don't\n> know.\n\nI'll be frank here. I think the main reason for a student to stick\naround is to see more of his code hit `master`. I think it is\nabsolutely essential to get students constantly post iteration after\niteration on the list. It would be nice to get them connected with 2~3\npeople in the community who will follow their progress and pitch in\neverytime they post an iteration. It might also make sense to stage\ntheir work in the main tree (a gsoc/ namespace?), so we can just\ncheckout to their branch to demo what they've done.\n\nAlso, we need more projects that will scratch everyday itches. A\ncollection of related tiny features might not be a bad idea. Often,\nwe risk erring on the side of too-big-for-one-summer when it comes to\nspecifying projects. What's the harm of including something estimated\nto take 80% of a summer?\n\nOn a related note, I don't like our Wiki. It's down half the time,\nand it's very badly maintained. I want to write content for our Wiki\nfrom the comfort of my editor, with version control aiding me. And I\ncan't stand archaic WikiText.\n"},{"id":"209699","messageId":"20130218185801.GA25673@sigill.intra.peff.net","threadId":"32927","inReplyTo":"CALkWK0nDEwgDwnVktmM8abv3ZgQmJCOm8LBe25UKR485PZMPfA@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-18T18:58:01Z","receivedAt":"2013-02-18T18:58:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote:\n\n> I'll be frank here. I think the main reason for a student to stick\n> around is to see more of his code hit `master`. I think it is\n> absolutely essential to get students constantly post iteration after\n> iteration on the list. It would be nice to get them connected with 2~3\n> people in the community who will follow their progress and pitch in\n> everytime they post an iteration. It might also make sense to stage\n> their work in the main tree (a gsoc/ namespace?), so we can just\n> checkout to their branch to demo what they've done.\n\nI agree. One of the main problems with GSoC projects is that the student\ngoes away and works for a while, and then at the end does not\nnecessarily have something mergeable. That is not how regular\ncontributors work. They post works in progress, get feedback, and\niterate on ideas. They break work into easily digestable and reviewable\nchunks. So maybe the mentors should be focusing more on that than on\nactual code problems.\n\n> Also, we need more projects that will scratch everyday itches. A\n> collection of related tiny features might not be a bad idea. Often,\n> we risk erring on the side of too-big-for-one-summer when it comes to\n> specifying projects. What's the harm of including something estimated\n> to take 80% of a summer?\n\nI very much agree with you here. One problem is that those smaller\nprojects often do not sound as grand or as interesting, and so students\ndo not propose them. We have to work with the applicants we get.\n\n> On a related note, I don't like our Wiki. It's down half the time,\n> and it's very badly maintained. I want to write content for our Wiki\n> from the comfort of my editor, with version control aiding me. And I\n> can't stand archaic WikiText.\n\nAgreed on all of those points. Putting the Wiki on GitHub fixes that.\nBut it means contributors need to have a GitHub account. On the other\nhand, I think kernel.org wiki contributors need an account these days?\nAnd GitHub is putting some active effort into finding and killing spammy\naccounts, which might keep wiki spam down (I do not pay too much\nattention to those efforts, but on kernel.org, it is mostly up to the\nGit community to do it ourselves).\n\n-Peff\n"},{"id":"209704","messageId":"20130218193424.GC3234@elie.Belkin","threadId":"32927","inReplyTo":"20130218174239.GB22832@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-18T19:34:24Z","receivedAt":"2013-02-18T19:34:24Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJeff King wrote:\n\n> I will do it again, if people feel strongly about Git being a part of\n> it. However, I have gotten a little soured on the GSoC experience. Not\n> because of anything Google has done; it's a good idea, and I think they\n> do a fine of administering the program. But I have noticed that the work\n> that comes out of GSoC the last few years has quite often not been\n> merged, or not made a big impact in the codebase, and nor have the\n> participants necessarily stuck around.\n\nI think that if we can commit enough time to mentor well it's\nworthwhile. Even such a negative result is useful, since it can teach\nus how good or poor we are at bringing new contributors in and what\nparts of that process need more work.\n\nThat said, I won't have time to mentor a project on my own. It takes\na lot of time (or luck, to get the student that doesn't need\nmentoring). I'd be happy to help on a project with 1 or 2 co-mentors.\n\nSome potential projects (unfiltered --- please take them with a grain\nof salt):\n\n - cross-compilable git\n\n - incorporation of the cgit web interface, or formalizing a subset of\n libgit.a to export as a stable library to it\n\n - merging the gitweb-caching fork\n\n - moving forward on a project that was the subject of a previous\n gsoc project: line-level logging, \"rebase --interactive\" on top of\n sequencer, usable svn remote helper\n\n - collapsable --first-parent history in gitk\n http://bugs.debian.org/600001\n\n - drag-and-drop cherry-pick in gitk\n\n - a sub-library of code shared with libgit2 (might be hard because\n our notions of strings are different :().\n\n - assimilating the distro builds: \"make deb-pkg\", \"make rpm-pkg\",\n etc along the same lines as the linux kernel's script/package/,\n to help people get recent git installed when they want it\n\n - \"please cherry-pick this before testing that\" notes for less\n scary bisecting\n\n - collaborative notes editing: fix the default notes refspec,\n make sure the \"notes pull\" workflow works well and is documented\n well, offer an easy way to hide private notes after the fact\n without disrupting public history\n\nHope that helps,\nJonathan\n"},{"id":"209706","messageId":"87fw0txv6r.fsf@pctrast.inf.ethz.ch","threadId":"32927","inReplyTo":"CALkWK0nDEwgDwnVktmM8abv3ZgQmJCOm8LBe25UKR485PZMPfA@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-02-18T19:45:32Z","receivedAt":"2013-02-18T19:45:32Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> [corrected David Barr's email address]\n>\n> Jeff King wrote:\n>> And I do not want to blame the students here (some of whom are on the cc\n>> list :) ). They are certainly under no obligation to stick around after\n>> GSoC ends, and I know they have many demands on their time. But I am\n>> also thinking about what Git wants to get out of GSoC (and to my mind,\n>> the most important thing is contributors).\n>>\n>> As far as merged code, I think part of the problem is that git is fairly\n>> mature at this point. The most interesting projects are of a bigger\n>> scope than a student with no experience in the code base can do in a\n>> summer project. Maybe that means we need to do a better job of breaking\n>> projects down into reasonably sized sub-components. Or maybe it means\n>> the project is hitting a point of diminishing returns for GSoC. I don't\n>> know.\n>\n> I'll be frank here. I think the main reason for a student to stick\n> around is to see more of his code hit `master`. I think it is\n> absolutely essential to get students constantly post iteration after\n> iteration on the list. It would be nice to get them connected with 2~3\n> people in the community who will follow their progress and pitch in\n> everytime they post an iteration. It might also make sense to stage\n> their work in the main tree (a gsoc/ namespace?), so we can just\n> checkout to their branch to demo what they've done.\n\nI agree, but I think there's an additional component. Consider the 'log\n-L' feature. It's fairly workable, and I merge it in my own builds and\nuse it, but there were and are two main issues:\n\n* The initial work by Bo was not in shape to be included, mostly because\n the code was too convoluted in the parts that process line ranges.\n\n* The last version I posted was held up because there's _in principle_ a\n better way to do things, but it requires major refactorings of\n existing code.\n\nI'm not going to try to discuss away the first one; it's also a failure\nof myself as mentor. However, as far as incomplete work goes, I think\nthe latter item is fairly symptomatic. We underestimate the amount of\nwork required to polish and reroll a submission that a student would\ndeem \"sufficiently working for inclusion\", fixes to be done later.\n\nSo I agree with your suggestion:\n\n> What's the harm of including something estimated to take 80% of a\n> summer?\n\nMaybe even less than 80%.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"209707","messageId":"CALkWK0kFYP4k5=237PZ3XHhxkzF-RWwwe=3+Thb_xU2Jw5tg2g@mail.gmail.com","threadId":"32927","inReplyTo":"20130218185801.GA25673@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-18T19:45:49Z","receivedAt":"2013-02-18T19:45:49Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote:\n>\n>> I'll be frank here. I think the main reason for a student to stick\n>> around is to see more of his code hit `master`. I think it is\n>> absolutely essential to get students constantly post iteration after\n>> iteration on the list. It would be nice to get them connected with 2~3\n>> people in the community who will follow their progress and pitch in\n>> everytime they post an iteration. It might also make sense to stage\n>> their work in the main tree (a gsoc/ namespace?), so we can just\n>> checkout to their branch to demo what they've done.\n>\n> I agree. One of the main problems with GSoC projects is that the student\n> goes away and works for a while, and then at the end does not\n> necessarily have something mergeable. That is not how regular\n> contributors work. They post works in progress, get feedback, and\n> iterate on ideas. They break work into easily digestable and reviewable\n> chunks.\n\n> So maybe the mentors should be focusing more on that than on\n> actual code problems.\n\nTake what I'm about to say with a pinch of salt, because I've never mentored.\n\nMentors often don't provide much technical assistance: students should\njust post to the list with queries, or ask on #git-devel. Mentors\nserve a different purpose; their primary responsibility, in my\nopinion, is to teach the student a sustainable productive workflow.\nThis means: profiling them to figure out where they're losing out. Do\nthey have the habit of:\n- posting to the list regularly?\n- CC'ing the right people?\n- iterating quickly after reviews?\n- using gdb efficiently to quickly understand parts?\n- using git efficiently for the rebase/ patch workflow?\n\n>> Also, we need more projects that will scratch everyday itches. A\n>> collection of related tiny features might not be a bad idea. Often,\n>> we risk erring on the side of too-big-for-one-summer when it comes to\n>> specifying projects. What's the harm of including something estimated\n>> to take 80% of a summer?\n>\n> I very much agree with you here. One problem is that those smaller\n> projects often do not sound as grand or as interesting, and so students\n> do not propose them. We have to work with the applicants we get.\n\nWe have to post well-crafted proposals like this to pique their interest.\n\n>> On a related note, I don't like our Wiki. It's down half the time,\n>> and it's very badly maintained. I want to write content for our Wiki\n>> from the comfort of my editor, with version control aiding me. And I\n>> can't stand archaic WikiText.\n>\n> Agreed on all of those points. Putting the Wiki on GitHub fixes that.\n> But it means contributors need to have a GitHub account. On the other\n> hand, I think kernel.org wiki contributors need an account these days?\n> And GitHub is putting some active effort into finding and killing spammy\n> accounts, which might keep wiki spam down (I do not pay too much\n> attention to those efforts, but on kernel.org, it is mostly up to the\n> Git community to do it ourselves).\n\nNo, I'm against using the GitHub Wiki for neutrality reasons. There\nis one easy way to fight spam: don't expose a web-based editing\ninterface at all. It's mainly going to be maintained by the\ncommunity, and we're all much more comfortable in our editors and git.\n We can give the regulars direct commit access and ask the rest to\nsubmit pull requests. Make it cost pennies, so any of us can easily\nafford it: just a cheap domain, DNS, and static HTML hosting.\n"},{"id":"209709","messageId":"87wqu5wgh9.fsf@pctrast.inf.ethz.ch","threadId":"32927","inReplyTo":"87fw0ta4ai.fsf@an-dro.info.enstb.org","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-02-18T19:48:34Z","receivedAt":"2013-02-18T19:48:34Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ronan Keryell writes:\n\n>>>>>> On Mon, 18 Feb 2013 18:46:05 +0100, Thomas Rast said:\n>\n> Thomas> The actual programming must be done in C using pthreads\n> Thomas> for obvious reasons.\n>\n> Are there obvious reasons OpenMP would not be enough to do the job?\n>\n> It looks like a trade-off between the code readability & portability\n> versus the real expressiveness of what parallelism control details are\n> needed.\n\nExcept for the added dependency you mean?\n\nI'm not sure exactly what the capabilities of OpenMP are that would help\nhere, but most likely it would work. It wouldn't really change the\namount of work needed, though, since the main work is in shuffling\naround the existing code paths to be amenable to parallel access in the\nfirst place. A \"dumb\" parallelization (i.e., just locking around all\nshared structures) POC yielded very little speedup because of lock\ncontention.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"209710","messageId":"87mwv1wg96.fsf@pctrast.inf.ethz.ch","threadId":"32927","inReplyTo":"CALkWK0ne3GX7wA1U0-TnMqU3mTFNe12TQ_s0=2MVJ=BMs8tirA@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2013-02-18T19:53:25Z","receivedAt":"2013-02-18T19:53:25Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ramkumar Ramachandra writes:\n\n>> * Cannot look at the diff in word-diff mode (and apply it normally).\n[...]\n> Also: Having to figure out, heuristically, when to actually turn it on\n> might be a worthwhile feature, especially for services like GitHub.\n\nActually that's a pretty cute idea of its own. You could call it\n--smart-diff or some such, and define its output as \"whatever diff\nformat git thinks would be appropriate\".\n\nAnd given the current state of diff pipeline refactorization, the effort\nis probably on the order of magnitude of a GSoC...\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"209712","messageId":"20130218195706.GD3234@elie.Belkin","threadId":"32927","inReplyTo":"CALkWK0kFYP4k5=237PZ3XHhxkzF-RWwwe=3+Thb_xU2Jw5tg2g@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-18T19:57:06Z","receivedAt":"2013-02-18T19:57:06Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> Take what I'm about to say with a pinch of salt, because I've never mentored.\n>\n> Mentors often don't provide much technical assistance: students should\n> just post to the list with queries, or ask on #git-devel. Mentors\n> serve a different purpose; their primary responsibility, in my\n> opinion, is to teach the student a sustainable productive workflow.\n\nI basically agree. One of the most important jobs of mentors is to\nmake sure there are people available to provide prompt technical\nassistance, hopefully before the project begins.\n\n[...]\n> - using gdb efficiently to quickly understand parts?\n\nOh, dear. I hope not. ;-)\n\nThanks,\nJonathan\n"},{"id":"209713","messageId":"512288B2.4090705@web.de","threadId":"32927","inReplyTo":"87fw0txv6r.fsf@pctrast.inf.ethz.ch","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-02-18T20:01:54Z","receivedAt":"2013-02-18T20:01:54Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 18.02.2013 20:45, schrieb Thomas Rast:\n> Ramkumar Ramachandra writes:\n>> What's the harm of including something estimated to take 80% of a\n>> summer?\n> \n> Maybe even less than 80%.\n\nI didn't regret at all having split the summer's topic I mentored\ninto smaller pieces. That made it easy to post patches to the list\nrather early (and IIRC some of them hit master before the end of\nthe GSoC).\n"},{"id":"209714","messageId":"512288B9.6010108@web.de","threadId":"32927","inReplyTo":"20130218193424.GC3234@elie.Belkin","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-02-18T20:02:01Z","receivedAt":"2013-02-18T20:02:01Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 18.02.2013 20:34, schrieb Jonathan Nieder:\n> That said, I won't have time to mentor a project on my own. It takes\n> a lot of time (or luck, to get the student that doesn't need\n> mentoring).\n\nThat's my experience too. Also I think it really makes sense to have a\nco-mentor so you can balance the load a bit.\n\n> I'd be happy to help on a project with 1 or 2 co-mentors.\n\nSame here.\n"},{"id":"209715","messageId":"878v6lwfrt.fsf@pctrast.inf.ethz.ch","threadId":"32927","inReplyTo":"CALkWK0kFYP4k5=237PZ3XHhxkzF-RWwwe=3+Thb_xU2Jw5tg2g@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-02-18T20:03:50Z","receivedAt":"2013-02-18T20:03:50Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ramkumar Ramachandra writes:\n\n[...]\n>>> On a related note, I don't like our Wiki. It's down half the time,\n>>> and it's very badly maintained. I want to write content for our Wiki\n>>> from the comfort of my editor, with version control aiding me. And I\n>>> can't stand archaic WikiText.\n>>\n>> Agreed on all of those points. Putting the Wiki on GitHub fixes that.\n>> But it means contributors need to have a GitHub account. On the other\n>> hand, I think kernel.org wiki contributors need an account these days?\n>> And GitHub is putting some active effort into finding and killing spammy\n>> accounts, which might keep wiki spam down (I do not pay too much\n>> attention to those efforts, but on kernel.org, it is mostly up to the\n>> Git community to do it ourselves).\n>\n> No, I'm against using the GitHub Wiki for neutrality reasons. There\n> is one easy way to fight spam: don't expose a web-based editing\n> interface at all. It's mainly going to be maintained by the\n> community, and we're all much more comfortable in our editors and git.\n> We can give the regulars direct commit access and ask the rest to\n> submit pull requests. Make it cost pennies, so any of us can easily\n> afford it: just a cheap domain, DNS, and static HTML hosting.\n\nI suppose since github's wiki system (gollum) is open source [1] it\nwouldn't be too hard to set up another instance somewhere. Bonus points\nfor importing all the old data in mediawiki format first, which is also\napparently supported.\n\nBut that just shifts the point of failure from the entire github team to\none or two people who end up administering the server.\n\nPerhaps a better solution would be to ask Scott or Peff to create a\ngollum instance under git-scm.com, which they're already hosting? (It\nseems people got over *that* neutrality issue quickly enough.) Push\nrights could be given to interested regulars. It would then at least be\nindependent in name.\n\n\nFootnotes: \n[1] https://github.com/github/gollum\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"209721","messageId":"CALkWK0mKZLotuu7pEM_3Of3i6JzU12QV_pHxOZTUr22TOq3PeQ@mail.gmail.com","threadId":"32927","inReplyTo":"20130218193424.GC3234@elie.Belkin","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-18T20:44:54Z","receivedAt":"2013-02-18T20:44:54Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> Hi,\n>\n> Jeff King wrote:\n>\n>> I will do it again, if people feel strongly about Git being a part of\n>> it. However, I have gotten a little soured on the GSoC experience. Not\n>> because of anything Google has done; it's a good idea, and I think they\n>> do a fine of administering the program. But I have noticed that the work\n>> that comes out of GSoC the last few years has quite often not been\n>> merged, or not made a big impact in the codebase, and nor have the\n>> participants necessarily stuck around.\n>\n> I think that if we can commit enough time to mentor well it's\n> worthwhile. Even such a negative result is useful, since it can teach\n> us how good or poor we are at bringing new contributors in and what\n> parts of that process need more work.\n\nThe point is that we must be willing to spend time learning what went\nwrong the previous summer, and how to improve upon it. There's no\npoint in doing a lather-rinse-repeat after many consecutive failures.\n\n> Some potential projects (unfiltered --- please take them with a grain\n> of salt):\n>\n> - cross-compilable git\n\nWhy, exactly? Git for embedded devices?\n\n> - incorporation of the cgit web interface, or formalizing a subset of\n> libgit.a to export as a stable library to it\n\nI didn't understand this: you want cgit in-tree?\n\n> - moving forward on a project that was the subject of a previous\n> gsoc project: line-level logging, \"rebase --interactive\" on top of\n> sequencer, usable svn remote helper\n\nI can't see a roadmap for gradually phasing out `rebase -i` as more\nand more of its functionality is built into the sequencer. Would you\nstart by using `cherry-pick --continue` in the special case of\nconsecutive `pick` or `revert` operations (yuck)? The sequencer\ncurrently has a continuation logic that we can leverage, but how will\nit call out to shell functions to do specific tasks (like `fixup`,\nwhich is not yet implemented)? Really, the only way I see is to\nduplicate the functionality of `rebase -i` in C, and throw away the\nshell script when we're sure we're done.\n\nFor usable svn remote helper, the major TODO is a git -> svn bridge.\nMy previous effort (which was a long time) was stalled because we\nneeded a way to persist blobs of text referenced by marks, and\nretrieve them on demand. Building this bridge is hard enough already,\nand I think we should just focus on an independent git -> svn bridge\nto put into contrib/svn-fi as a deliverable. It doesn't have to have\nanything to do with remote helpers at all.\n\n> - drag-and-drop cherry-pick in gitk\n\nYou expect someone to write Tcl/Tk today? Do a `git log gitk-git/`\nand tell me how many people are writing it.\n\n> - a sub-library of code shared with libgit2 (might be hard because\n> our notions of strings are different :().\n>\n> - assimilating the distro builds: \"make deb-pkg\", \"make rpm-pkg\",\n> etc along the same lines as the linux kernel's script/package/,\n> to help people get recent git installed when they want it\n\nOverkill. I just symlink to bin-wrapper/git from a place high up in\nmy $PATH. If anything, we should be making it easier for ourselves to\nrun different versions of git right from $HOME, much like rbenv.\nSystem-wide installs are taken care of by the distribution package\nmanagers, and I doubt they need any help from us.\n\n> - collaborative notes editing: fix the default notes refspec,\n> make sure the \"notes pull\" workflow works well and is documented\n> well, offer an easy way to hide private notes after the fact\n> without disrupting public history\n\nI personally don't care for notes much, because I can't see practical\nusecases. I'd much rather fix something that's much more widely used\nand broken: submodules.\n"},{"id":"209724","messageId":"20130218205532.GB27308@sigill.intra.peff.net","threadId":"32927","inReplyTo":"20130218193424.GC3234@elie.Belkin","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-18T20:55:32Z","receivedAt":"2013-02-18T20:55:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 18, 2013 at 11:34:24AM -0800, Jonathan Nieder wrote:\n\n> Some potential projects (unfiltered --- please take them with a grain\n> of salt):\n> [...]\n> - collaborative notes editing: fix the default notes refspec,\n> make sure the \"notes pull\" workflow works well and is documented\n> well, offer an easy way to hide private notes after the fact\n> without disrupting public history\n\nI know you said a grain of salt, so please don't feel like I'm beating\nup on your idea. I'm picking this one because I think it has some\ncharacteristics of projects that have not gone well in the past, so it's\na good illustrative example.\n\nIMHO, this is the type of project that is likely to fail, because most\nof the work is not technical at all, but political. Changing the default\nrefspecs is a few lines of code. But the hard part is figuring out where\nthey should go, the implications of doing so, and how people are going\nto react. And it's intimately tied to how we have considered refactoring\nthe default ref namespaces, which is a messy discussion with a lot of\ndifferent options (and implications, and backwards compatibility issues,\netc). Plans need to be laid for deprecating old things, and handling the\ntransition to the new thing. Lines need to be drawn about what is in the\nproject and what isn't.\n\nBringing a project like that to completion is going to involve a lot of\ncommunity involvement. And that's the thing students are historically\nthe worst at it. I think it's _also_ the most valuable thing they can\nlearn. But I think it doesn't make for a very gentle introduction to\nopen source.\n\nAgain, just my two cents. I don't want to dissuade anybody from this\nproject in particular, or this style of project. I'm more trying to\nbring up discussion on how and why projects fail.\n\n-Peff\n"},{"id":"209734","messageId":"20130218210709.GC27308@sigill.intra.peff.net","threadId":"32927","inReplyTo":"CALkWK0mKZLotuu7pEM_3Of3i6JzU12QV_pHxOZTUr22TOq3PeQ@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-18T21:07:09Z","receivedAt":"2013-02-18T21:07:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 19, 2013 at 02:14:54AM +0530, Ramkumar Ramachandra wrote:\n\n> > - assimilating the distro builds: \"make deb-pkg\", \"make rpm-pkg\",\n> > etc along the same lines as the linux kernel's script/package/,\n> > to help people get recent git installed when they want it\n> \n> Overkill. I just symlink to bin-wrapper/git from a place high up in\n> my $PATH. If anything, we should be making it easier for ourselves to\n> run different versions of git right from $HOME, much like rbenv.\n> System-wide installs are taken care of by the distribution package\n> managers, and I doubt they need any help from us.\n\nThis is not related to GSoC anymore, but I think handling multiple\nversions is already pretty easy. You can just install to\n\"$HOME/local/git/$TAGNAME\" or similar, and then symlink the \"bin/git\"\nbinary from there into your PATH as git.$TAGNAME (e.g., git.v1.7.8). Git\nalready takes care of the messy bits, like making sure sub-programs are\ninvoked from the same git version.\n\nI already do this automagically with this script:\n\n https://github.com/peff/git/blob/meta/install/prefix\n\nI just set \"prefix\" in the Makefile based on the script, and when I\n\"make install\" tags or topic branches, they go to the right place (and\nthe \"links\" script in the same directory maintains the symlinks for me).\n\nI never bothered to even submit those scripts to contrib, because I\nfigured they were so specific to my setup, and to keeping dozens of git\nversions around (when debugging, it's nice to be able to check an old\nversion's behavior without even having to build it).\n\nOf course that has nothing to do with Jonathan's proposal. I do agree\nthat it is pretty straightforward to just put $BUILD_DIR/bin-wrappers in\nyour PATH and be done. I guess that doesn't cover manpages, though (but\nReal Programmers just read the source anyway, right?).\n\n-Peff\n"},{"id":"209735","messageId":"20130218211101.GA4022@elie.Belkin","threadId":"32927","inReplyTo":"CALkWK0mKZLotuu7pEM_3Of3i6JzU12QV_pHxOZTUr22TOq3PeQ@mail.gmail.com","subject":"Potential GSoC13 projects (Re: Google Summer of Code 2013 (GSoC13))","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-18T21:11:01Z","receivedAt":"2013-02-18T21:11:01Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Jonathan Nieder wrote:\n\n>> - cross-compilable git\n>\n> Why, exactly? Git for embedded devices?\n\nMy personal motivation would be building Git for Windows while\nspending as little time on Windows as possible. People deploying git\nto 32-bit x86, 64-bit x86, and ARM (think \"ARM laptops\") might also\nfind it handy.\n\n>> - incorporation of the cgit web interface, or formalizing a subset of\n>> libgit.a to export as a stable library to it\n>\n> I didn't understand this: you want cgit in-tree?\n\nYes, or a stable API that cgit out-of-tree can use.\n\n>> - moving forward on a project that was the subject of a previous\n>> gsoc project: line-level logging, \"rebase --interactive\" on top of\n>> sequencer, usable svn remote helper\n>\n> I can't see a roadmap for gradually phasing out `rebase -i` as more\n> and more of its functionality is built into the sequencer.\n\nIt's a break-the-world thing. \"rebase -i --experimental\".\n\n[...]\n> For usable svn remote helper, the major TODO is a git -> svn bridge.\n\nThere are other major TODOs, too.\n\n[...]\n>> - drag-and-drop cherry-pick in gitk\n>\n> You expect someone to write Tcl/Tk today?\n\nSure, why not? Tcl is not actually too unpleasant of a language.\n\nMaybe it has a prerequisite, though:\n\n - \"modular gitk\" (splitting gitk into digestible pieces)\n\n[...]\n>> - assimilating the distro builds:\n[...]\n> Overkill.\n\nMy itch is that it would let me send packaging patches to the list\nand get the usual high-quality feedback. Oh well. ;-)\n\n[...]\n>> - collaborative notes editing: fix the default notes refspec,\n>> make sure the \"notes pull\" workflow works well and is documented\n>> well, offer an easy way to hide private notes after the fact\n>> without disrupting public history\n>\n> I personally don't care for notes much, because I can't see practical\n> usecases.\n\nAre you sure that's not because of the poor current state of\ncollaborative notes editing?\n\nSome example use cases:\n\n - marking regressions discovered later, to warn people bisecting or\n cherry-picking\n\n - matching up to corresponding commits in another repository\n\n - link to corresponding mailing list discussion, blog post, or\n related patches\n\n - a wiki-like document storing review comments\n\n - marking which CVE this fixes, once the CVE number has been\n allocated\n\n - \"a tour of the project\" for new contributors, using explanatory\n notes that end with a mention the next commit to look at\n\nI'm not married to the current implementation, but I think the basic\nidea of \"git notes\" is a promising feature that could use some polish.\n\nJonathan\n"},{"id":"209736","messageId":"20130218211321.GD27308@sigill.intra.peff.net","threadId":"32927","inReplyTo":"CALkWK0kFYP4k5=237PZ3XHhxkzF-RWwwe=3+Thb_xU2Jw5tg2g@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-18T21:13:21Z","receivedAt":"2013-02-18T21:13:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 19, 2013 at 01:15:49AM +0530, Ramkumar Ramachandra wrote:\n\n> Take what I'm about to say with a pinch of salt, because I've never mentored.\n> \n> Mentors often don't provide much technical assistance: students should\n> just post to the list with queries, or ask on #git-devel. Mentors\n> serve a different purpose; their primary responsibility, in my\n> opinion, is to teach the student a sustainable productive workflow.\n> This means: profiling them to figure out where they're losing out. Do\n> they have the habit of:\n> - posting to the list regularly?\n> - CC'ing the right people?\n> - iterating quickly after reviews?\n> - using gdb efficiently to quickly understand parts?\n> - using git efficiently for the rebase/ patch workflow?\n\nI think you are spot-on. Those are the things that students need to\nlearn to do, and what mentors should be pushing them towards. But it\nseems like we have the same problems with it year after year, and I know\nmentors have worked on it. I'm not sure where the problem is.\n\n> > I very much agree with you here. One problem is that those smaller\n> > projects often do not sound as grand or as interesting, and so students\n> > do not propose them. We have to work with the applicants we get.\n> \n> We have to post well-crafted proposals like this to pique their interest.\n\nTrue. I think we can bear some of the blame in the proposal writing. But\nif you look at the applications each year, they tend to cluster around\none or two projects, and most projects get no hits at all. It could be\nbecause they're badly written. But I think it is also that they are not\nin areas that are as flashy (and the flashiness often correlates with\ncomplexity).\n\n> No, I'm against using the GitHub Wiki for neutrality reasons.\n\nFair enough. I have the same reservations.\n\n> There is one easy way to fight spam: don't expose a web-based editing\n> interface at all. It's mainly going to be maintained by the\n> community, and we're all much more comfortable in our editors and git.\n> We can give the regulars direct commit access and ask the rest to\n> submit pull requests. Make it cost pennies, so any of us can easily\n> afford it: just a cheap domain, DNS, and static HTML hosting.\n\nI'd be totally fine with that. You'd need to pick a static generator\nframework (I don't think it is a good idea for everybody to be writing\nraw html). I suspect kernel.org would be happy to host the static pages,\nbut if not, GitHub can pick up the hosting tab (and we could probably do\nit as a subdomain under git-scm.com, too, if people want).\n\n-Peff\n"},{"id":"209744","messageId":"7vip5p9rtm.fsf@alter.siamese.dyndns.org","threadId":"32927","inReplyTo":"CALkWK0nDEwgDwnVktmM8abv3ZgQmJCOm8LBe25UKR485PZMPfA@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-18T22:32:05Z","receivedAt":"2013-02-18T22:32:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> [corrected David Barr's email address]\n>\n> Jeff King wrote:\n>> And I do not want to blame the students here (some of whom are on the cc\n>> list :) ). They are certainly under no obligation to stick around after\n>> GSoC ends, and I know they have many demands on their time. But I am\n>> also thinking about what Git wants to get out of GSoC (and to my mind,\n>> the most important thing is contributors).\n>>\n>> As far as merged code, I think part of the problem is that git is fairly\n>> mature at this point. The most interesting projects are of a bigger\n>> scope than a student with no experience in the code base can do in a\n>> summer project. Maybe that means we need to do a better job of breaking\n>> projects down into reasonably sized sub-components. Or maybe it means\n>> the project is hitting a point of diminishing returns for GSoC. I don't\n>> know.\n>\n> Also, we need more projects that will scratch everyday itches. A\n> collection of related tiny features might not be a bad idea. Often,\n> we risk erring on the side of too-big-for-one-summer when it comes to\n> specifying projects. What's the harm of including something estimated\n> to take 80% of a summer?\n\nI think the real issue is everybody in the GSoC mentor candidate\npool grossly underestimates the scope of suggested projects, does\nnot encourage students to send early drafts to the public from the\nbeginning, and perhaps overestimates the ability of total beginners.\nAfter seeing my \"index-thing is too big in scope\" warning repeatedly\nignored for the last year's GSoC, I am not very hopeful unless the\nattitude towards GSoC and its students drastically changes on our\nmentors' end.\n\nWe have solicited \"suggested projects\" entries via wiki in the past,\nletting anybody to put anything there, and I think that was a major\nsource of our past failures. The practice lets irresponsive people\nwho think they know what they are talking about to place unrealistic\npie-in-the-sky there. I wonder if we can somehow come up with a way\nto limit them to realisitic ones in a sane way. One possibility may\nbe to require the proposer to already have an 80% answer, not to be\nshared with students. A project that a GSoC student who is not\nfamiliar with our codebase and culture (e.g. our no regressions\npolicy and requiring solid transition plan for disruptive changes)\nis expected to finish in a summer should not be bigger than what a\nmentor familiar with our project can do a rough outline design and\nimplementation as a two-weekend hack at most, I think.\n\nSuch a requirement on the proposer's end may be a reasonable sanity\ncheck to make sure we do not suggest sure-to-fail projects to the\nstudents.\n\nIt is ironic that I have to point out that the best \"let's get\nstudents exposed to the OSS process using Git community's reviewing\nbandwidth\" last year from my point of view happened outside the\nGSoC. Matthieu's school projects were not structured to the GSoC\nstandard (they assigned multiple students working together on each\ntopic), but the size of the projects seemed more manageable. It was\na joy to work with these students during the term of the project. We\nhad a meaningful number of review iterations, unlike a typical GSoC\nproject where a student and her mentors sit in a dark cave for a\nlong time, send out the first draft too late, and the participant do\nnot get enough time to do meaningful iterations of reviews (it was\nalso a huge plus from our project's point of view that there were\neven responsible post-program follow up to complete the unfinished\nbits).\n"},{"id":"209745","messageId":"7vehgd9rkg.fsf@alter.siamese.dyndns.org","threadId":"32927","inReplyTo":"20130218210709.GC27308@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-18T22:37:35Z","receivedAt":"2013-02-18T22:37:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> This is not related to GSoC anymore, but I think handling multiple\n> versions is already pretty easy. You can just install to\n> \"$HOME/local/git/$TAGNAME\" or similar, and then symlink the \"bin/git\"\n> binary from there into your PATH as git.$TAGNAME (e.g., git.v1.7.8). Git\n> already takes care of the messy bits, like making sure sub-programs are\n> invoked from the same git version.\n>\n> I already do this automagically with this script:\n>\n> https://github.com/peff/git/blob/meta/install/prefix\n>\n> I just set \"prefix\" in the Makefile based on the script, and when I\n> \"make install\" tags or topic branches, they go to the right place (and\n> the \"links\" script in the same directory maintains the symlinks for me).\n>\n> I never bothered to even submit those scripts to contrib, because I\n> figured they were so specific to my setup, and to keeping dozens of git\n> versions around (when debugging, it's nice to be able to check an old\n> version's behavior without even having to build it).\n\nYeah, I have been using the Make (in the todo branch, to be checked\nout in Meta/ subdirectory of the working tree) script for exactly\nthis. After tagging a release, I'd do\n\n\tgit checkout -B snap v1.8.1.3\n Meta/Make install install-doc\n\nto install them in $inst_prefix/git-snap-v1.8.1.3. A \"rungit\"\nscript can then be used like:\n\n\trungit v1.7.0 checkout blah\n\n-- rungit script -- >8 -- rungit script --\n#!/bin/sh\n# Run various vintage of git\n\nvariant=\"${0##*/}\" &&\n: ${RUNGIT_BASE=$HOME/g/$(getarch)} &&\ncase \"$variant\" in\nrungit)\n\tcase $# in \n\t0)\n\t\techo >&2 \"which version?\"\n\t\texit 1\n\t\t;;\n\tesac\n\tvariant=$1\n\tshift\n\t;;\nesac &&\ncase \"$variant\" in\n-l)\n\tfor d in \"$RUNGIT_BASE/\"git-*/bin/git\n\tdo\n\t\td=$(basename ${d%/bin/git})\n\t\td=${d#git-}\n\t\td=${d#snap-}\n\t\techo \"$d\"\n\tdone\n\texit\n\t;;\ngit-*)\n\tvariant=${variant#git-} ;;\nv[0-9]*)\n\tvariant=snap-$variant ;;\nesac &&\nd=\"$RUNGIT_BASE/git-$variant\" &&\nif test -f \"$d/bin/git\"\nthen\n\texec \"$d/bin/git\" \"$@\"\nelse\n\techo >&2 \"$variant: No such variant for $a\"\n\texit 1\nfi\n"},{"id":"209751","messageId":"20130218230303.GC4022@elie.Belkin","threadId":"32927","inReplyTo":"20130218205532.GB27308@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-18T23:03:03Z","receivedAt":"2013-02-18T23:03:03Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n> On Mon, Feb 18, 2013 at 11:34:24AM -0800, Jonathan Nieder wrote:\n\n>> Some potential projects (unfiltered --- please take them with a grain\n>> of salt):\n>> [...]\n>> - collaborative notes editing: fix the default notes refspec,\n>> make sure the \"notes pull\" workflow works well and is documented\n>> well, offer an easy way to hide private notes after the fact\n>> without disrupting public history\n>\n> I know you said a grain of salt, so please don't feel like I'm beating\n> up on your idea. I'm picking this one because I think it has some\n> characteristics of projects that have not gone well in the past, so it's\n> a good illustrative example.\n>\n> IMHO, this is the type of project that is likely to fail, because most\n> of the work is not technical at all, but political. Changing the default\n> refspecs is a few lines of code. But the hard part is figuring out where\n> they should go, the implications of doing so, and how people are going\n> to react.\n\nI think I agree, if by \"likely to fail\" you mean \"easy to underestimate\nthe difficulty of\". I actually think it would be a pretty good summer\nstudent project, for a few related reasons:\n\n * Years of evidence show it is a hard problem. It would be a good\n notch in the belt of whoever takes the project on.\n\n * It does not require a deep understanding of git internals. A good\n familiarity with the git user interface, on the other hand, would\n be essential, but I hope that is becoming more common among\n students these days.\n\n * It requires good taste and design sense, which are something it\n would be nice to cultivate and encourage.\n\n * The change is necessary and the satisfaction of helping a student\n through the process might be enough to finally get it done.\n\n * If an amazing candidate finishes the \"make collaboration possible\"\n task early, there's plenty of valuable, interesting, and technically\n complicated follow-on work regarding the related \"share some notes\n while hiding others\" to fill the rest of the summer.\n\nThe code change for the most basic subset of \"make collaboration\npossible\" would presumably be a changed refspec, some documentation,\nand some tests. On top of that there is presumably some automagic\nincorporation of upstream notes to be cooked into \"git pull\". Some\nbetter conflict-resolution magic. Example scripts to generate notes.\nSupport for the format-patch / am workflow. gitweb support for\nshowing notes.\n\nIt's a good example of when it's useful to not be afraid of failing to\nplease everybody and just get something done.\n\nI also can't think of any examples of such technically straightforward\nstudent projects being tried before.\n\nJonathan\n"},{"id":"209756","messageId":"CACsJy8CCotnPo0C_o_0721O2w3dqXUWAYjCjgeEYQzq-CdX14g@mail.gmail.com","threadId":"32927","inReplyTo":"87ehgd1qq2.fsf@pctrast.inf.ethz.ch","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-02-19T01:17:42Z","receivedAt":"2013-02-19T01:17:42Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 19, 2013 at 12:23 AM, Thomas Rast wrote:\n> * Naturally that ideas page is a bit stale now, and three projects\n> shorter. Please propose new ideas and refresh or delete the old ones!\n> In particular some projects spawned long discussions on the list, and\n> the results of those discussions should be integrated to avoid deja\n> vus.\n\nA proposal from what I've been involved lately: inotify support to\neliminate lstat and readdir syscalls. The scope may be small. But we\ncould aim to get it merged in master or at least next by the end of\nGSoC. Or extend to another platform besides Linux, it helps ensure we\nhave good abstraction. My free time goes up and down unexpectedly, not\nsure if I can commit to be a mentor. But I'm definitely interested and\nwill support whenever I can.\n-- \nDuy\n"},{"id":"209757","messageId":"CACsJy8Arotg-fRk-pDGE_MHzah2apyt45co0JzJ4Roy_24EPBw@mail.gmail.com","threadId":"32927","inReplyTo":"20130218211101.GA4022@elie.Belkin","subject":"Re: Potential GSoC13 projects (Re: Google Summer of Code 2013 (GSoC13))","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-02-19T01:23:11Z","receivedAt":"2013-02-19T01:23:11Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 19, 2013 at 4:11 AM, Jonathan Nieder wrote:\n> Ramkumar Ramachandra wrote:\n>> Jonathan Nieder wrote:\n>\n>>> - cross-compilable git\n>>\n>> Why, exactly? Git for embedded devices?\n>\n> My personal motivation would be building Git for Windows while\n> spending as little time on Windows as possible. People deploying git\n> to 32-bit x86, 64-bit x86, and ARM (think \"ARM laptops\") might also\n> find it handy.\n\nI did something like that long ago (for cross compiling Windows).\nAlthough I eventually gave up on the Windows front as I was too lazy\nto test on Windows :) (and Wine by that time was not good enough) I\nthink some of my patches are in the archive. Will dig them up.\n-- \nDuy\n"},{"id":"209771","messageId":"CALkWK0=s4XX0mmUTAcNBHyqdrryhMYvhtrNZCFFccJJBUUVdUg@mail.gmail.com","threadId":"32927","inReplyTo":"7vip5p9rtm.fsf@alter.siamese.dyndns.org","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-19T07:08:51Z","receivedAt":"2013-02-19T07:08:51Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Ramkumar Ramachandra writes:\n>\n>> [corrected David Barr's email address]\n>>\n>> Jeff King wrote:\n>>> And I do not want to blame the students here (some of whom are on the cc\n>>> list :) ). They are certainly under no obligation to stick around after\n>>> GSoC ends, and I know they have many demands on their time. But I am\n>>> also thinking about what Git wants to get out of GSoC (and to my mind,\n>>> the most important thing is contributors).\n>>>\n>>> As far as merged code, I think part of the problem is that git is fairly\n>>> mature at this point. The most interesting projects are of a bigger\n>>> scope than a student with no experience in the code base can do in a\n>>> summer project. Maybe that means we need to do a better job of breaking\n>>> projects down into reasonably sized sub-components. Or maybe it means\n>>> the project is hitting a point of diminishing returns for GSoC. I don't\n>>> know.\n>>\n>> Also, we need more projects that will scratch everyday itches. A\n>> collection of related tiny features might not be a bad idea. Often,\n>> we risk erring on the side of too-big-for-one-summer when it comes to\n>> specifying projects. What's the harm of including something estimated\n>> to take 80% of a summer?\n>\n> I think the real issue is everybody in the GSoC mentor candidate\n> pool grossly underestimates the scope of suggested projects, does\n> not encourage students to send early drafts to the public from the\n> beginning, and perhaps overestimates the ability of total beginners.\n> After seeing my \"index-thing is too big in scope\" warning repeatedly\n> ignored for the last year's GSoC, I am not very hopeful unless the\n> attitude towards GSoC and its students drastically changes on our\n> mentors' end.\n\nThe short undiplomatic version of that is that our mentors suck (I'm\nnot pointing fingers, but that's what I infer from failing projects).\nIn my opinion, there is no point putting up proposed mentors for\nprojects in advance: ideal mentors are people who are interested in\nthe students, more than the project proposals.\n\n> We have solicited \"suggested projects\" entries via wiki in the past,\n> letting anybody to put anything there, and I think that was a major\n> source of our past failures. The practice lets irresponsive people\n> who think they know what they are talking about to place unrealistic\n> pie-in-the-sky there. I wonder if we can somehow come up with a way\n> to limit them to realisitic ones in a sane way. One possibility may\n> be to require the proposer to already have an 80% answer, not to be\n> shared with students. A project that a GSoC student who is not\n> familiar with our codebase and culture (e.g. our no regressions\n> policy and requiring solid transition plan for disruptive changes)\n> is expected to finish in a summer should not be bigger than what a\n> mentor familiar with our project can do a rough outline design and\n> implementation as a two-weekend hack at most, I think.\n\nThe Wiki is often polluted with arbitrary, useless, unrealistic\nprojects. We expect students to pick up from a small writeup on the\nWiki and come up with everything else, and I think this is a mistake.\nFurther, I think burdening one pre-chosen mentor with all the\ngroundwork is a terrible idea.\n\nI propose that we have one thread for every proposal where we can all\ndiscuss the implementation outline- this will serve as authoritative\nsource of information for students, and for picking mentors (the\npeople who contribute most to the discussion). Students should be\nmatched with mentors on an individual basis.\n\n> Such a requirement on the proposer's end may be a reasonable sanity\n> check to make sure we do not suggest sure-to-fail projects to the\n> students.\n\nThe discussion thread will automatically tell us which projects are\nbadly thought-out and unrealistic.\n"},{"id":"209773","messageId":"20130219072512.GI19757@elie.Belkin","threadId":"32927","inReplyTo":"CALkWK0=s4XX0mmUTAcNBHyqdrryhMYvhtrNZCFFccJJBUUVdUg@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-19T07:25:12Z","receivedAt":"2013-02-19T07:25:12Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> The short undiplomatic version of that is that our mentors suck (I'm\n> not pointing fingers, but that's what I infer from failing projects).\n\nHold on a second. I'm not remembering such a grim outcome with 100%\nfailure from prior summers of code as you're describing. Before I\nstart beating myself up, I guess I'd like a little more information\n--- is there some specific project or statistic that you're thinking\nof that brings you to that conclusion?\n\n[...]\n> I propose that we have one thread for every proposal where we can all\n> discuss the implementation outline- this will serve as authoritative\n> source of information for students, and for picking mentors (the\n> people who contribute most to the discussion). Students should be\n> matched with mentors on an individual basis.\n\nHow is that different from what happened in previous summers where\nstudents made proposals, received feedback, and were accepted and\nmatched to mentors or rejected based on how the discussion went?\n\nJonathan\n"},{"id":"209775","messageId":"7v7gm492ty.fsf@alter.siamese.dyndns.org","threadId":"32927","inReplyTo":"CALkWK0=s4XX0mmUTAcNBHyqdrryhMYvhtrNZCFFccJJBUUVdUg@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-19T07:31:53Z","receivedAt":"2013-02-19T07:31:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Junio C Hamano wrote:\n> ...\n>> I think the real issue is everybody in the GSoC mentor candidate\n>> pool grossly underestimates the scope of suggested projects, does\n>> not encourage students to send early drafts to the public from the\n>> beginning, and perhaps overestimates the ability of total beginners.\n>> After seeing my \"index-thing is too big in scope\" warning repeatedly\n>> ignored for the last year's GSoC, I am not very hopeful unless the\n>> attitude towards GSoC and its students drastically changes on our\n>> mentors' end.\n>\n> The short undiplomatic version of that is that our mentors suck (I'm\n> not pointing fingers, but that's what I infer from failing projects).\n\nI was conflating between people who add \"suggested project\" and who\nact as mentors. I do not think mentors are primarily responsible\nfor bad suggested projects.\n\nOur mentors may be wonderful but I do not have enough evidence to\njudge either way. They are mostly student-facing and I as a\nbystander to GSoC process didn't see much of their involvement in\ntheir students' work---maybe that is how it is supposed to work,\nmaybe not. The only failing of them observable from my point of\nview was that we repeatedly saw the initial round of patches come\nvery late.\n\nBut my complaints were primarily about those sure-to-fail project\nsuggestions.\n\n> I propose that we have one thread for every proposal where we can all\n> discuss the implementation outline- this will serve as authoritative\n> source of information for students, and for picking mentors (the\n> people who contribute most to the discussion). Students should be\n> matched with mentors on an individual basis.\n\nYou are being unreasonable and/or unrealistic. A topic that needs a\nlarge discussion thread to pre-discuss design and outline by many\nexisting members of community and mentor candidates is a sure sign\nthat the topic is too big for a beginner. A topic that needs only a\nsmall enough discussion thread on the other hand will come to a\npolished conclusion before even the student shows up. \n\nThis is exactly why I suggested \"doable as a private, at most\ntwo-weekend hack by an experienced\" as a quick and dirty way to\nmeasure the size of a project.\n"},{"id":"209777","messageId":"CALkWK0=_kpmUOYS5J6L2+JPzmeW_9+bVAu4eN=dr8kPMbuTn8w@mail.gmail.com","threadId":"32927","inReplyTo":"878v6lwfrt.fsf@pctrast.inf.ethz.ch","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-19T07:51:43Z","receivedAt":"2013-02-19T07:51:43Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Thomas Rast wrote:\n> Ramkumar Ramachandra writes:\n>\n> [...]\n>>>> On a related note, I don't like our Wiki. It's down half the time,\n>>>> and it's very badly maintained. I want to write content for our Wiki\n>>>> from the comfort of my editor, with version control aiding me. And I\n>>>> can't stand archaic WikiText.\n>>>\n>>> Agreed on all of those points. Putting the Wiki on GitHub fixes that.\n>>> But it means contributors need to have a GitHub account. On the other\n>>> hand, I think kernel.org wiki contributors need an account these days?\n>>> And GitHub is putting some active effort into finding and killing spammy\n>>> accounts, which might keep wiki spam down (I do not pay too much\n>>> attention to those efforts, but on kernel.org, it is mostly up to the\n>>> Git community to do it ourselves).\n>>\n>> No, I'm against using the GitHub Wiki for neutrality reasons. There\n>> is one easy way to fight spam: don't expose a web-based editing\n>> interface at all. It's mainly going to be maintained by the\n>> community, and we're all much more comfortable in our editors and git.\n>> We can give the regulars direct commit access and ask the rest to\n>> submit pull requests. Make it cost pennies, so any of us can easily\n>> afford it: just a cheap domain, DNS, and static HTML hosting.\n>\n> I suppose since github's wiki system (gollum) is open source [1] it\n> wouldn't be too hard to set up another instance somewhere. Bonus points\n> for importing all the old data in mediawiki format first, which is also\n> apparently supported.\n\nYes, I am aware. However, I don't think gollum fits our purposes\nwell: we really don't need much more than plain text.\nWhat do you want to import? We can copy out the text from the\nprevious GSoC pages, but most of the other pages are filled with\nancient junk. We don't want a museum: we want a clean Wiki with\ncrisp, clean up-to-date information.\n\n> But that just shifts the point of failure from the entire github team to\n> one or two people who end up administering the server.\n\n... which is the entire problem. We don't want to \"administer\"\nthings. We're programmers who're competent at writing plain text and\nmaintaining git repositories, so let's stick to doing that; I'm\npushing for static HTML hosting for exactly this reason: there is\nnothing to \"administer\", no security exploits, no unexpected\nbreakages. It also reflects our community's affinity for simplicity.\n\n> Perhaps a better solution would be to ask Scott or Peff to create a\n> gollum instance under git-scm.com, which they're already hosting?\n\nFailing that, just a CNAME entry for \"wiki\" under git-scm.com would\nsuffice. What does static HTML hosting cost anyway?\n\n> (It\n> seems people got over *that* neutrality issue quickly enough.)\n\nThere's a big difference between having git-scm.com as our official\nwebsite, and hosting our official Wiki on\nhttps://github.com/git/git/wiki. Although it is built by people\nworking in GitHub, with its sources in github.com/github/gitscm-next,\nit makes no effort to reference GitHub directly.\n\nOfcourse, there are many things I dislike about the website, and would\nhave preferred a community-built one. Unfortunately, building a\nwebsite involves doing design work that we programmers are incompetent\nat. So, I think of it as a practical compromise that we have to live\nwith.\n"},{"id":"209778","messageId":"CALkWK0nnkfrHi-0=c-bXdBHaOeBsCdccZDJZX5LDs0dT=SsReg@mail.gmail.com","threadId":"32927","inReplyTo":"20130219072512.GI19757@elie.Belkin","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-19T08:12:35Z","receivedAt":"2013-02-19T08:12:35Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> Ramkumar Ramachandra wrote:\n>\n>> The short undiplomatic version of that is that our mentors suck (I'm\n>> not pointing fingers, but that's what I infer from failing projects).\n>\n> Hold on a second. I'm not remembering such a grim outcome with 100%\n> failure from prior summers of code as you're describing. Before I\n> start beating myself up, I guess I'd like a little more information\n> --- is there some specific project or statistic that you're thinking\n> of that brings you to that conclusion?\n\nIn retrospect, I might have been unnecessarily harsh there.\n\nOne of the main measures of a mentor's success, in my opinion, is\nhaving his student stick around after the Summer of Code: the mentor\nis the student's primary link to the community. There have been 4~5\nstudents every year, times 6 years (is that how long we've been\nparticipating?). How many of those students have felt part of the\ncommunity?\n"},{"id":"209779","messageId":"CALkWK0=zpZ25X_jVBoF77E75kmV38VC+nwtQ6MYA9=UO99HqyQ@mail.gmail.com","threadId":"32927","inReplyTo":"7v7gm492ty.fsf@alter.siamese.dyndns.org","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-19T08:22:17Z","receivedAt":"2013-02-19T08:22:17Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Ramkumar Ramachandra writes:\n>\n>> Junio C Hamano wrote:\n>> ...\n>>> I think the real issue is everybody in the GSoC mentor candidate\n>>> pool grossly underestimates the scope of suggested projects, does\n>>> not encourage students to send early drafts to the public from the\n>>> beginning, and perhaps overestimates the ability of total beginners.\n>>> After seeing my \"index-thing is too big in scope\" warning repeatedly\n>>> ignored for the last year's GSoC, I am not very hopeful unless the\n>>> attitude towards GSoC and its students drastically changes on our\n>>> mentors' end.\n>>\n>> The short undiplomatic version of that is that our mentors suck (I'm\n>> not pointing fingers, but that's what I infer from failing projects).\n>\n> I was conflating between people who add \"suggested project\" and who\n> act as mentors. I do not think mentors are primarily responsible\n> for bad suggested projects.\n\nWhy do mentors pick badly sketched-out projects to mentor? They're\nfree to pick anything they want/ propose what they want.\n\n> Our mentors may be wonderful but I do not have enough evidence to\n> judge either way. They are mostly student-facing and I as a\n> bystander to GSoC process didn't see much of their involvement in\n> their students' work---maybe that is how it is supposed to work,\n> maybe not. The only failing of them observable from my point of\n> view was that we repeatedly saw the initial round of patches come\n> very late.\n\nIdeally, the initial round of patches should come in well before the\nGSoC even starts, I think (the initial round might just be doing some\nminor surrounding work though).\n\n>> I propose that we have one thread for every proposal where we can all\n>> discuss the implementation outline- this will serve as authoritative\n>> source of information for students, and for picking mentors (the\n>> people who contribute most to the discussion). Students should be\n>> matched with mentors on an individual basis.\n>\n> You are being unreasonable and/or unrealistic. A topic that needs a\n> large discussion thread to pre-discuss design and outline by many\n> existing members of community and mentor candidates is a sure sign\n> that the topic is too big for a beginner. A topic that needs only a\n> small enough discussion thread on the other hand will come to a\n> polished conclusion before even the student shows up.\n\nI that case, projects like inotify support that Duy suggested in a\nnearby thread are not realistic candidates. No, I wouldn't like huge\ndiscussion threads on each proposal either: but a ~10 email thread\nwith everyone's thoughts on it would be useful, I think. If the size\nof the thread exceeds a certain threshold, the project is deemed\nun-doable automatically.\n\n> This is exactly why I suggested \"doable as a private, at most\n> two-weekend hack by an experienced\" as a quick and dirty way to\n> measure the size of a project.\n\nYes, that's a good measure.\n"},{"id":"209781","messageId":"874nh8vgoo.fsf@pctrast.inf.ethz.ch","threadId":"32927","inReplyTo":"CALkWK0nnkfrHi-0=c-bXdBHaOeBsCdccZDJZX5LDs0dT=SsReg@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-02-19T08:41:43Z","receivedAt":"2013-02-19T08:41:43Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Jonathan Nieder wrote:\n>> Ramkumar Ramachandra wrote:\n>>\n>>> The short undiplomatic version of that is that our mentors suck (I'm\n>>> not pointing fingers, but that's what I infer from failing projects).\n>>\n>> Hold on a second. I'm not remembering such a grim outcome with 100%\n>> failure from prior summers of code as you're describing. Before I\n>> start beating myself up, I guess I'd like a little more information\n>> --- is there some specific project or statistic that you're thinking\n>> of that brings you to that conclusion?\n>\n> In retrospect, I might have been unnecessarily harsh there.\n>\n> One of the main measures of a mentor's success, in my opinion, is\n> having his student stick around after the Summer of Code: the mentor\n> is the student's primary link to the community. There have been 4~5\n> students every year, times 6 years (is that how long we've been\n> participating?). How many of those students have felt part of the\n> community?\n\nIn defense of Thomas, whose project was mentioned earlier as a prime\nexample of something that is \"too big\":\n\nHe's in fact still working on the index-API angle, as part of a thesis\nat university.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"209782","messageId":"CALkWK0kdjKXAiOz6k-Anfb3Xut5apZbQ-rqYhkA73YRu83tLcw@mail.gmail.com","threadId":"32927","inReplyTo":"20130218211321.GD27308@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-19T09:00:11Z","receivedAt":"2013-02-19T09:00:11Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> On Tue, Feb 19, 2013 at 01:15:49AM +0530, Ramkumar Ramachandra wrote:\n>\n>> Take what I'm about to say with a pinch of salt, because I've never mentored.\n>>\n>> Mentors often don't provide much technical assistance: students should\n>> just post to the list with queries, or ask on #git-devel. Mentors\n>> serve a different purpose; their primary responsibility, in my\n>> opinion, is to teach the student a sustainable productive workflow.\n>> This means: profiling them to figure out where they're losing out. Do\n>> they have the habit of:\n>> - posting to the list regularly?\n>> - CC'ing the right people?\n>> - iterating quickly after reviews?\n>> - using gdb efficiently to quickly understand parts?\n>> - using git efficiently for the rebase/ patch workflow?\n>\n> I think you are spot-on. Those are the things that students need to\n> learn to do, and what mentors should be pushing them towards. But it\n> seems like we have the same problems with it year after year, and I know\n> mentors have worked on it. I'm not sure where the problem is.\n\nI essentially have a couple of suggestions:\n- Be more thorough about discussing proposals; pick mentors from those\nwho are deeply involved in the discussion, and are interested in the\nstudent.\n- Increase the visibility of every GSoC project in the community.\nLike I suggested earlier, a set of GSoC branches in-tree would be a\ngreat start: it's easy to go through the `log`, and tell if the\nstudent has been idle for a while. We can put up links to the GitHub\ngraphs for each of these branches.\n\n>> > I very much agree with you here. One problem is that those smaller\n>> > projects often do not sound as grand or as interesting, and so students\n>> > do not propose them. We have to work with the applicants we get.\n>>\n>> We have to post well-crafted proposals like this to pique their interest.\n>\n> True. I think we can bear some of the blame in the proposal writing. But\n> if you look at the applications each year, they tend to cluster around\n> one or two projects, and most projects get no hits at all. It could be\n> because they're badly written. But I think it is also that they are not\n> in areas that are as flashy (and the flashiness often correlates with\n> complexity).\n\nWe need to collaborate on proposal writing, I think (which is why I\nsuggested one-thread-per-proposal in a different email). In the past,\nit has mostly been one person writing the entire thing.\n\n>> There is one easy way to fight spam: don't expose a web-based editing\n>> interface at all. It's mainly going to be maintained by the\n>> community, and we're all much more comfortable in our editors and git.\n>> We can give the regulars direct commit access and ask the rest to\n>> submit pull requests. Make it cost pennies, so any of us can easily\n>> afford it: just a cheap domain, DNS, and static HTML hosting.\n>\n> I'd be totally fine with that. You'd need to pick a static generator\n> framework (I don't think it is a good idea for everybody to be writing\n> raw html). I suspect kernel.org would be happy to host the static pages,\n> but if not, GitHub can pick up the hosting tab (and we could probably do\n> it as a subdomain under git-scm.com, too, if people want).\n\nOfcourse. Nobody wants to write raw HTML. Additionally, I'd love it\nif we could post new posts via email, since we already have the habit\nof writing emails.\n"},{"id":"209834","messageId":"7vtxp86zcs.fsf@alter.siamese.dyndns.org","threadId":"32927","inReplyTo":"874nh8vgoo.fsf@pctrast.inf.ethz.ch","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-19T16:29:55Z","receivedAt":"2013-02-19T16:29:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> In defense of Thomas, whose project was mentioned earlier as a prime\n> example of something that is \"too big\":\n>\n> He's in fact still working on the index-API angle, as part of a thesis\n> at university.\n\nThat is probably a good indicator that it was too big for a summer\nstudent. It also is good to hear that the topic is being looked at\n;-).\n"},{"id":"209835","messageId":"7vppzw6z7z.fsf@alter.siamese.dyndns.org","threadId":"32927","inReplyTo":"CALkWK0=zpZ25X_jVBoF77E75kmV38VC+nwtQ6MYA9=UO99HqyQ@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-19T16:32:48Z","receivedAt":"2013-02-19T16:32:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n>> I was conflating between people who add \"suggested project\" and who\n>> act as mentors. I do not think mentors are primarily responsible\n>> for bad suggested projects.\n>\n> Why do mentors pick badly sketched-out projects to mentor? They're\n> free to pick anything they want/ propose what they want.\n\nI've had an impression that these Wiki entries were written by\npeople with names of mentors (who are different from the proposers)\nalready assigned to them, and if an unfortunate student picked an\nunrealistic one, these mentor candidates were too nice to push back\nand decline, saying \"it is unrealistic\", leaving the student and\nproposal without any mentor.\n"},{"id":"209836","messageId":"871uccs1f3.fsf@pctrast.inf.ethz.ch","threadId":"32927","inReplyTo":"7vtxp86zcs.fsf@alter.siamese.dyndns.org","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-02-19T16:39:44Z","receivedAt":"2013-02-19T16:39:44Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano writes:\n\n> Thomas Rast writes:\n>\n>> In defense of Thomas, whose project was mentioned earlier as a prime\n>> example of something that is \"too big\":\n>>\n>> He's in fact still working on the index-API angle, as part of a thesis\n>> at university.\n>\n> That is probably a good indicator that it was too big for a summer\n> student. It also is good to hear that the topic is being looked at\n> ;-).\n\nNot really: the API angle was never part of the proposal. The timeline\nwas [1 if you have access]:\n\n 24/04 - 01/05: Document the new index format.\n 02/05 - 11/05: Create a converter of the old index format to the new format.\n 12/05 - 18/06: Parse the index from disk to the current in-memory format. The\n old index format shall still be readable.\n 19/06 - 09/07: Implement the re-reading of a single record, if the crc32 doesn't\n match (Meaning the record has been changed under the reader).\n 10/07 - 21/07: Map the current internal structure to the new index format.\n 22/07 - 31/07: Change the current in-memory structure to keep track of the\n changed files.\n 01/08 - 13/08: Write the index to disk in both the old and the new format\n depending on the choice of the user and make sure only the changed parts are\n really written to disk in the new format.\n 11/08 - 13/08: Test the new index and profile the gains compared to the old\n format.\n /* Development work will be a bit slower from 18/06 to 21/07 because at my\n * University there are exams in this period. I probably will only be able to\n * work half the hours. I'll be back up to full speed after that. */\n\nI think this case is somewhat symptomatic for one possible cause of\ndragged-out non-inclusions _after_ GSoC: there's a certain scope creep\ncaused by striving for the perfect, long-term maintainable code.\n\nThe solution IMHO is to _both_ recognize such possibilities for scope\ncreep, and cut down the proposals to a size where a student has a\nreasonable chance of achieving the code quality required for inclusion.\n\n(The latter option has been mentioned a few times, but I wanted to make\npeople aware that the scope creep is happening, too.)\n\n\nFootnotes: \n[1] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/tgummerer/1\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"209885","messageId":"CAP8UFD1cUmefNPL65dj1KOxzaPsoZ3XTNT9XDuUm3ABAm5rCzQ@mail.gmail.com","threadId":"32927","inReplyTo":"512288B9.6010108@web.de","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2013-02-20T06:17:48Z","receivedAt":"2013-02-20T06:17:48Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Feb 18, 2013 at 9:02 PM, Jens Lehmann wrote:\n> Am 18.02.2013 20:34, schrieb Jonathan Nieder:\n>> That said, I won't have time to mentor a project on my own. It takes\n>> a lot of time (or luck, to get the student that doesn't need\n>> mentoring).\n>\n> That's my experience too. Also I think it really makes sense to have a\n> co-mentor so you can balance the load a bit.\n>\n>> I'd be happy to help on a project with 1 or 2 co-mentors.\n>\n> Same here.\n\nI am ok to be mentor or co-mentor.\n\nThanks,\nChristian.\n"},{"id":"209887","messageId":"CAJo=hJvknVedGba5OxjjvZi2=JZyDuDoP2tD+LKQKdZNJ4NcsA@mail.gmail.com","threadId":"32927","inReplyTo":"20130218174239.GB22832@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2013-02-20T06:50:26Z","receivedAt":"2013-02-20T06:50:26Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Mon, Feb 18, 2013 at 9:42 AM, Jeff King wrote:\n> On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote:\n>\n>> * We need an org admin. AFAIK this was done by Peff and Shawn in\n>> tandem last year. Would you do it again?\n>\n> I will do it again, if people feel strongly about Git being a part of\n> it. However, I have gotten a little soured on the GSoC experience. Not\n> because of anything Google has done; it's a good idea, and I think they\n> do a fine of administering the program. But I have noticed that the work\n> that comes out of GSoC the last few years has quite often not been\n> merged, or not made a big impact in the codebase, and nor have the\n> participants necessarily stuck around.\n\nThis.\n\nI actually think Git should take a year off from GSoC and not\nparticipate. Consequently I will not be volunteering as backup org\nadmin.\n\nGit has been involved since 2007. In all of that time we have had very\nfew student projects merge successfully into their upstream project\n(e.g. git.git, JGit or libgit2) before the end of GSoC. Even fewer\nstudents have stuck around and remained active contributors. When I\nlook at the amount of effort we contributors put into GSoC, I think we\nare misusing our limited time and resources. The intention of the GSoC\nprogram is to grow new open source developers, and increase our\ncommunity of contributors. Somehow I think Git is falling well short\nof its potential here. This is especially true if you compare Git's\nGSoC program to some other equally long-running GSoC programs.\n\n> And I do not want to blame the students here (some of whom are on the cc\n> list :) ). They are certainly under no obligation to stick around after\n> GSoC ends, and I know they have many demands on their time. But I am\n> also thinking about what Git wants to get out of GSoC (and to my mind,\n> the most important thing is contributors).\n\nI agree, our students have been pretty terrific. I think the\nshortcomings in our GSoC program are on the mentoring side. Our\nprogram has not really had much success with keeping students active\nand engaged post GSoC. I see that primarily as a mentoring failure.\nAnd its one we keep repeating each year.\n\n> As far as merged code, I think part of the problem is that git is fairly\n> mature at this point. The most interesting projects are of a bigger\n> scope than a student with no experience in the code base can do in a\n> summer project. Maybe that means we need to do a better job of breaking\n> projects down into reasonably sized sub-components. Or maybe it means\n> the project is hitting a point of diminishing returns for GSoC. I don't\n> know.\n\nLet me repeat myself. I think our GSoC program has plenty of room for\nimprovement on the mentoring side. Project scope and size is one of\nour most common failure modes. Resumable clone keeps winding up on the\nGSoC project idea list. Nobody who knows what they are talking about\nhas any idea how to approach this feature[1]. Suggesting it to a GSoC\nstudent is just irresponsible[2].\n\nI don't think Git's maturity is a road block for successful GSoC\nprojects. Peff's toy to insert Lua so `git log` could do fancy\nformatting is an interesting one. I suspect there are still fun\narcheology sorts of projects that could further improve the type of\ndata we can mine through log and blame. But touching the core file\nformats on disk or the wire protocol is probably far too large for a\nGSoC project.\n\n[1] Android's \"repo\" tool and its /clone.bundle hack on HTTP\ntransports might work. Peff has talked about putting this into Git\nitself one day. Maybe. But its still full of a ton of shortcomings and\nsomewhat hated by those that have to build the bundles and manage the\nserver infrastructure. So its probably still outside of the scope of a\nsuccessful GSoC project.\n\n[2] I recognize and accept my share of blame for putting it on the\nlist a few times.\n\n> There are a few counterpoints I can think of:\n>\n> - Even though not all projects are winners, _some_ are. I see Carlos\n> and Ram on the cc list, two people who started as GSoC students and\n> stuck around.\n\nI think these interesting cases like Carlos and Ram are places where\nthe student was able to succeed almost despite our mentoring program.\nI am very glad they did.\n\n> - There is also the angle that even if _Git_ doesn't benefit directly\n> from people sticking around, those people may float into other open\n> source projects and work on them. Which makes the world a better\n> place on the whole.\n\nYes, sure, OK. But if Git doesn't participate in GSoC this year\nanother org will, and this same benefit will still be had by the\ngreater open source community.\n"},{"id":"209907","messageId":"CAP8UFD01bUgUz1LST6DPjhQ4qsNEA4-ndpLQ97XqH_fOEdew9w@mail.gmail.com","threadId":"32927","inReplyTo":"CAJo=hJvknVedGba5OxjjvZi2=JZyDuDoP2tD+LKQKdZNJ4NcsA@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2013-02-20T12:07:15Z","receivedAt":"2013-02-20T12:07:15Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Wed, Feb 20, 2013 at 7:50 AM, Shawn Pearce wrote:\n> On Mon, Feb 18, 2013 at 9:42 AM, Jeff King wrote:\n>> On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote:\n>>\n>>> * We need an org admin. AFAIK this was done by Peff and Shawn in\n>>> tandem last year. Would you do it again?\n>>\n>> I will do it again, if people feel strongly about Git being a part of\n>> it. However, I have gotten a little soured on the GSoC experience. Not\n>> because of anything Google has done; it's a good idea, and I think they\n>> do a fine of administering the program. But I have noticed that the work\n>> that comes out of GSoC the last few years has quite often not been\n>> merged, or not made a big impact in the codebase, and nor have the\n>> participants necessarily stuck around.\n>\n> This.\n\nI think it is ok if the code doesn't make a big impact in the code\nbase and it is ok too if the participants don't stuck around.\nOf course I would love both of these things to happen, but we have to\nbe realistic and just stop expecting it.\n\n> I actually think Git should take a year off from GSoC and not\n> participate. Consequently I will not be volunteering as backup org\n> admin.\n>\n> Git has been involved since 2007. In all of that time we have had very\n> few student projects merge successfully into their upstream project\n> (e.g. git.git, JGit or libgit2) before the end of GSoC. Even fewer\n> students have stuck around and remained active contributors. When I\n> look at the amount of effort we contributors put into GSoC, I think we\n> are misusing our limited time and resources.\n\nI don't think so, at least not for me. I feel happy to mentor or\nco-mentor GSoC student and I don't think I would work much more on git\nthese days if git was not participating to the GSoC.\n\n> The intention of the GSoC\n> program is to grow new open source developers, and increase our\n> community of contributors. Somehow I think Git is falling well short\n> of its potential here. This is especially true if you compare Git's\n> GSoC program to some other equally long-running GSoC programs.\n>\n>> And I do not want to blame the students here (some of whom are on the cc\n>> list :) ). They are certainly under no obligation to stick around after\n>> GSoC ends, and I know they have many demands on their time. But I am\n>> also thinking about what Git wants to get out of GSoC (and to my mind,\n>> the most important thing is contributors).\n>\n> I agree, our students have been pretty terrific. I think the\n> shortcomings in our GSoC program are on the mentoring side. Our\n> program has not really had much success with keeping students active\n> and engaged post GSoC. I see that primarily as a mentoring failure.\n> And its one we keep repeating each year.\n\nI don't quite agree with this. My experience has been the following:\n\n- 2008: the student I co-mentored did pretty well though he didn't\nsend to the list his patch series early enough.\nSo there was some mentoring failure, but anyway the student stuck\naround for 9 months and managed to get 53 commits merged.\n\n- 2009: if I remember well, it was decided to have only 2 GSoC student\nthat year, and that 5 people would co-mentor both of them together.\nOne of the student did nearly nothing. The other one sent his patch\nseries too late to the list. My opinion is that he relied too much on\nthe people mentoring him and he worked on something that was difficult\nto merge.\n\n- 2010: the student I co-mentored stopped working 3 weeks before the\nmid-term evaluation despite some warnings from me and Peff, and he had\nnot been doing much a few weeks before that, so we decided to fail him\nat the mid term evaluation.\n\n- 2011: I was lucky to mentor Ram who did well and is still around.\n\nSo my opinion is that we have some students who are just not doing\nenough (2 out of 5).\nThen we have some good students, 2 out of 5 who could sometimes do\nbetter if we insisted more on submitting earlier to the mailing list.\nAnd we have a few students (1 out of 5) who work difficult to merge\nprojects and who could do better if we insisted more on submitting\nearlier to the mailing list.\n\nSo my conclusions are:\n- it's quite often going well or well enough\n- when it's not going well often the student is responsible\n- yes, we could improve mentoring by providing better projects and\ninsisting even more on submitting earlier\n\n[...]\n\n>> - There is also the angle that even if _Git_ doesn't benefit directly\n>> from people sticking around, those people may float into other open\n>> source projects and work on them. Which makes the world a better\n>> place on the whole.\n>\n> Yes, sure, OK. But if Git doesn't participate in GSoC this year\n> another org will, and this same benefit will still be had by the\n> greater open source community.\n\nThe greater open source community benefits a lot these days when Git\nis improved and get new contributors, as git is now by far the most\nwidely used version control system in the open source community.\nSo my opinion is that we should have has many GSoC student as we can\nproperly handle.\n\nBest regards,\nChristian.\n"},{"id":"209908","messageId":"vpqip5nb281.fsf@grenoble-inp.fr","threadId":"32927","inReplyTo":"CAP8UFD01bUgUz1LST6DPjhQ4qsNEA4-ndpLQ97XqH_fOEdew9w@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-02-20T12:26:38Z","receivedAt":"2013-02-20T12:26:38Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Christian Couder writes:\n\n> - yes, we could improve mentoring by providing better projects and\n> insisting even more on submitting earlier\n\nA few words about my experience, not with GSoC, but with school projects\n(I've been proposing a few students in Ensimag to contribute to Git each\nyear since 2010).\n\nLast year, we've been using Scrum, and the \"definition of done\" was a\nvery helpful tool. In Scrum, nothing is ever \"half done\", it is either\n\"done\" or \"not done\". Out of a 3 weeks project, the definition of done\nwas initially \"ready to be sent to the list\", then \"sent to the list, no\nmajor criticism in reviews\" the second week, and \"sent to the list, no\nmore objections in reviews\" the last week. At the beginning of each week\n(\"sprint\" in Scrum), students were commiting to a list of tasks, and at\nthe end of each week, we evaluated how many were done. This encouraged\nstudents to avoid overcommiting and send patches early. Some of them\nvalidated nothing at all the first week: they hadn't realized the\ndistance between their notion of clean working code and the one on this\nlist, but at least they realized it early enough.\n\nOf course, even with that, I had to continue the work to push it to\nmaster for some patch series, and discard some series that were\nbasically not there.\n\nHaving several small projects instead of one big was very important. I'm\nnot sure how the GSoC would feel about a list of small tasks instead of\none ambitious project however.\n\nMy main disappointment is that I never managed to keep students in the\ncommunity past the end of the project.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"209932","messageId":"51252877.5000808@schu.io","threadId":"32927","inReplyTo":"20130218174239.GB22832@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Michael Schubert","fromEmail":"schu@schu.io","sentAt":"2013-02-20T19:48:07Z","receivedAt":"2013-02-20T19:48:07Z","isPatch":false,"sender":{"key":"schu@schu.io","avatar":null},"body":"On 02/18/2013 06:42 PM, Jeff King wrote:\n> \n> I will do it again, if people feel strongly about Git being a part of\n> it. However, I have gotten a little soured on the GSoC experience. Not\n> because of anything Google has done; it's a good idea, and I think they\n> do a fine of administering the program. But I have noticed that the work\n> that comes out of GSoC the last few years has quite often not been\n> merged, or not made a big impact in the codebase, and nor have the\n> participants necessarily stuck around.\n> \n> And I do not want to blame the students here (some of whom are on the cc\n> list :) ). They are certainly under no obligation to stick around after\n> GSoC ends, and I know they have many demands on their time. But I am\n> also thinking about what Git wants to get out of GSoC (and to my mind,\n> the most important thing is contributors).\n\nSpeaking of libgit2:\n\nGit provided the libgit2 project with a slot each of the last three GSOC.\nThe contributions made by the former students (Disclaimer: one of them\nspeaking) have been quite important for libgit2 and all three students\nare still involved. Each project was an important push towards building\na new, feature complete Git library.\n\nThank you!\n\nhttp://libgit2.github.com\n"},{"id":"209975","messageId":"87wqu1zqn4.fsf@centaur.cmartin.tk","threadId":"32927","inReplyTo":"51252877.5000808@schu.io","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Carlos Martín Nieto","fromEmail":"cmn@delego.de","sentAt":"2013-02-21T14:29:51Z","receivedAt":"2013-02-21T14:29:51Z","isPatch":false,"sender":{"key":"cmn@delego.de","avatar":null},"body":"Michael Schubert writes:\n\n> On 02/18/2013 06:42 PM, Jeff King wrote:\n>> \n>> I will do it again, if people feel strongly about Git being a part of\n>> it. However, I have gotten a little soured on the GSoC experience. Not\n>> because of anything Google has done; it's a good idea, and I think they\n>> do a fine of administering the program. But I have noticed that the work\n>> that comes out of GSoC the last few years has quite often not been\n>> merged, or not made a big impact in the codebase, and nor have the\n>> participants necessarily stuck around.\n>> \n>> And I do not want to blame the students here (some of whom are on the cc\n>> list :) ). They are certainly under no obligation to stick around after\n>> GSoC ends, and I know they have many demands on their time. But I am\n>> also thinking about what Git wants to get out of GSoC (and to my mind,\n>> the most important thing is contributors).\n>\n> Speaking of libgit2:\n>\n> Git provided the libgit2 project with a slot each of the last three GSOC.\n> The contributions made by the former students (Disclaimer: one of them\n> speaking) have been quite important for libgit2 and all three students\n> are still involved. Each project was an important push towards building\n> a new, feature complete Git library.\n\nRight, speaking of libgit2. GSoC has been very successful (as Michael,\nI'm also somewhat biased) for libgit2. This happens outside of the git\nML so it probably hasn't gotten as much visibility here.\n\nI believe it's partly because there were still larger parts where most\nof the work was technical and the goal was quite clear, as git had\nalready set the standard and expectations and the decisions had to be\nmostly about how to implement it in a way that makes sense for a\nlibrary, rather than it living inside of git, which is not always easy,\nbut you can experiment with different uses of it.\n\nIt's also possible that part of the success was the fact that we were\nalready acquainted with the \"release often and early\" policy, as we'd\nbeen involved with FLOSS for a while already.\n\nThe current gaping hole in libgit2 is the lack of merge support, which\nis the last hurdle to a stable 1.0 release. There is already some work\nby Edward Thomson that needs to be reviewed and merged. I'm not sure\nthat there's enough for a whole summer there, but you could throw in the\nreview and merge of another missing feature, which is making the\nreference storage generic, as it currently only supports the\ngit-compatible file-based one. There's other nice-to-have things like\nthin-pack support that you could use to fill up a summer, though I'm not\nsure that goes with the spirit of the programme.\n\nSomething else that needs love is Git for Windows. I believe both git\nand libgit2 would benefit a lot from a project to take some parts of git\nthat are implemented in a scripting language and port them to use\nlibgit2. As Git for Windows needs to ship a ton of dependencies anyway,\nusing a pre-1.0 library wouldn't be an issue and it can be used to\nexperiment with an eventual porting of git to be one user of libgit2\nrather than a completely different implementation. The more immediate\nbenefit for Git for Windows would be less reliance on languages that are\nawkward to use on Windows and need their own environment. Mentoring from\nthe libgit2 probably wouldn't be much of an issue to organise, though\nI'm not sure if the GfW team would have time for the part that involves\nits peculiarities.\n\nSo there's a couple of projects that could be done with some realistic\nchance of being merged upstream, as they'd be technical, as long as we\ndo tell the student to send small units of work to be reviewed often.\n\nCheers,\n cmn\n"},{"id":"209976","messageId":"877gm1brnv.fsf@pctrast.inf.ethz.ch","threadId":"32927","inReplyTo":"CAJo=hJvknVedGba5OxjjvZi2=JZyDuDoP2tD+LKQKdZNJ4NcsA@mail.gmail.com","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-02-21T15:41:40Z","receivedAt":"2013-02-21T15:41:40Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Shawn Pearce writes:\n\n> On Mon, Feb 18, 2013 at 9:42 AM, Jeff King wrote:\n>> On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote:\n>>\n>>> * We need an org admin. AFAIK this was done by Peff and Shawn in\n>>> tandem last year. Would you do it again?\n>>\n>> I will do it again, if people feel strongly about Git being a part of\n>> it. However, I have gotten a little soured on the GSoC experience. Not\n>> because of anything Google has done; it's a good idea, and I think they\n>> do a fine of administering the program. But I have noticed that the work\n>> that comes out of GSoC the last few years has quite often not been\n>> merged, or not made a big impact in the codebase, and nor have the\n>> participants necessarily stuck around.\n>\n> This.\n>\n> I actually think Git should take a year off from GSoC and not\n> participate. Consequently I will not be volunteering as backup org\n> admin.\n\nFair enough. But I think if that's the decision (and modulo libgit2\npraise, it seems to be pretty much the consensus?), we should probably\nhave some Idea why we are doing it?\n\nYou wrote:\n\n> Git has been involved since 2007. In all of that time we have had very\n> few student projects merge successfully into their upstream project\n> (e.g. git.git, JGit or libgit2) before the end of GSoC. Even fewer\n> students have stuck around and remained active contributors. When I\n> look at the amount of effort we contributors put into GSoC, I think we\n> are misusing our limited time and resources. The intention of the GSoC\n> program is to grow new open source developers, and increase our\n> community of contributors. Somehow I think Git is falling well short\n> of its potential here. This is especially true if you compare Git's\n> GSoC program to some other equally long-running GSoC programs.\n\nIf that's the outset (and it's certainly true for a lot of the\nprojects), aren't the options (not limited to just one):\n\n* We have some discussion about why we fail, what to do better, etc. and\n hopefully also manage to clean up some old projects and get them\n included. That way we can learn something from it.\n\n* We try to look at how more successful communities are doing it\n (e.g. there were some posts about how KDE bumped their student\n retention rate).\n\n* We try to \"mentor\" some projects that aren't GSoC sponsered. That way\n we can hope to gain mentoring experience.\n\nI'm not very optimistic about any of these, as:\n\n- There weren't any in-depth discussions post-GSoC to analyze what went\n wrong.\n\n- Contributor time is so limited that we're usually short on reviews.\n Adding \"mentoring for the sake of trying it\" to duties isn't very\n promising.\n\nThus I'm a bit afraid that after a year off, we won't have learned\nanything new. To the contrary, some previous mentors/students will\ninevitably have disappeared into the mists of time, and with them their\nexperience. Unless we do something about it, next year we'll be in an\n_even worse_ position than this year.\n\nI'm mildly pessimistic about \"doing something\" over the list, but\nperhaps we can have an extended discussion at git-merge provided enough\nof you show up there? I can try to prepare some material.\n\n\n(Maybe we should all make a bunch of clones of ourselves. We can put\none copy each into a room so they can figure out GSoC, and have another\ngroup doing our favorite git hacking while we're at it.)\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"210243","messageId":"453931856.Va6j4WpQCl@flomedio","threadId":"32927","inReplyTo":"20130218174239.GB22832@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Florian Achleitner","fromEmail":"florian.achleitner2.6.31@gmail.com","sentAt":"2013-02-25T09:12:18Z","receivedAt":"2013-02-25T09:12:18Z","isPatch":false,"sender":{"key":"florian.achleitner.2.6.31@gmail.com","avatar":"https://avatars.githubusercontent.com/u/880777?v=4"},"body":"[corrected David Barr's address]\nOn Monday 18 February 2013 12:42:39 Jeff King wrote:\n> And I do not want to blame the students here (some of whom are on the cc\n> list ). They are certainly under no obligation to stick around after\n> GSoC ends, and I know they have many demands on their time. But I am\n> also thinking about what Git wants to get out of GSoC (and to my mind,\n> the most important thing is contributors).\n\nJust a little comment from another student:\nLast year i worked on the 'remote helper for svn'. My official mentor was David \nBarr, but I had most interaction with Jonathan Nieder.\n\n>From my point of view I wouldn't say the project was a fail. It was harder \nthan I originally thought, yes. That happens.\nBut we have a remote helper in master now, although its far from complete and \nit's development is quite stalled. (remote-testsvn)\n\nAbout sticking around:\nAs you can see I read the list (I was not on CC), but not very regularly, I \nadmit. Anyways, I'd respond to mails in CC or on IRC.\n\nDuring the summer I believe I learned git's development process quite well. I \nrerolled my main patch series 8 times until 19th of September, which is well \nbeyond GSOC deadline. I tried to get it finished before concentrating on my \nstudies again.\n\nIf I would now continue to contribute, it would be a completely new topic \n(like branch mapping) and take a lot of time that I don't have during the \nyear, where I have to push my studies forward. \nFor a student one aspect of GSOC is also quite important: It is a cool and \ndemanding summer job during the holidays, but it has to ramp down when the new \nsemester starts.\n\nAnyways I think GSOC is a great idea and I enjoyed contributing to git a lot, \nwould immediatly do it again. Keep it goin'!\nThanks.\n\nFlorian\n"},{"id":"210256","messageId":"7vd2voz3tr.fsf@alter.siamese.dyndns.org","threadId":"32927","inReplyTo":"453931856.Va6j4WpQCl@flomedio","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-25T17:44:00Z","receivedAt":"2013-02-25T17:44:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Florian Achleitner writes:\n\n> For a student one aspect of GSOC is also quite important: It is a cool and \n> demanding summer job during the holidays, but it has to ramp down when the new \n> semester starts.\n\nThanks for sharing.\n\nI think an important lesson is that mentors and reviewers need to\nthink really hard to limit the initial scope of the assignment to be\nnot too ambitious. Starting with an ambitious goal and achieving\nonly small first steps of them _can_ still be a good end result, but\nif a mentor wants to go that route, the decision to cut down the\nscope of an ambitous assignment needs to be made early enough to\nleave sufficient time to wrap up the half-done assignment in a good\nshape. Finishing with implementation of only the initial 30% of an\nunproven design, that by itself is not useful, does not help our\nproject at all, and it does not give satisfaction to the student,\neither.\n"},{"id":"210315","messageId":"CAH-tXsAPWuF3bBSMJF-rjxhn0bfMOJ-RVUaNz4rWT_hoQJdg2w@mail.gmail.com","threadId":"32927","inReplyTo":"87ehgd1qq2.fsf@pctrast.inf.ethz.ch","subject":"Re: Google Summer of Code 2013 (GSoC13)","fromName":"Jaseem Abid","fromEmail":"jaseemabid@gmail.com","sentAt":"2013-02-26T04:59:54Z","receivedAt":"2013-02-26T04:59:54Z","isPatch":false,"sender":{"key":"jaseemabid@gmail.com","avatar":"https://gravatar.com/avatar/8b0432c96e4d3c8a9a96c9961ee842df7b7a869744da9c25187a51a992eabd81?d=mp&s=160"},"body":"On Mon, Feb 18, 2013 at 10:53 PM, Thomas Rast wrote:\n\n> * We should prepare an \"ideas page\". Last year, Peff made one on\n> https://github.com/peff/git/wiki/SoC-2012-Ideas\n\n[Resending the mail, because the last one failed because of inline html content]\n\nOne of the proposed ideas last year - 'Use JavaScript library /\nframework in gitweb'\n\nI wanted to work on this project last year, but Git community didn't\nget a slot for the project from Google. I still worked on it and\nalmost finished it. Sadly I never got time to polish it to merge to\nmaster. you can see some of my commits on it here.\nhttps://github.com/jaseemabid/git/commits/gitweb\n\nDetailed notes on what actually did.\nhttps://gist.github.com/jaseemabid/3218461\n\n\nGitweb is 1 huge perl script and even though it *works*, it is a poor\nwork in 2013. The code is pretty old and is a hard thing to jump into.\nQuite a few here helped me to get started and it was a pretty good\nexperience. Jakub was the mentor. Ram and John 'warthog' Hawley\noccasionally helped with git and general feedback back then. Andrew\nSayers helped a lot, but he just\ndisappeared one day. I remember John mentioning about splitting the\nfile into smaller ones, rewriting some sections, adding more\ndocumentation etc. I'm not sure if any work was done on this. I\ncouldn't follow the project for sometime.\n\nI will try to make some time and finish it off in the next week or so.\nI am having a bad schedule now between school and job, but will try my\nlevel best.\n\n--\nRegards,\n\nJaseem Abid\ngithub.com/jaseemabid\n"}]}