On Mon, Feb 18, 2013 at 9:42 AM, Jeff King <peff@xxxxxxxx> wrote: > On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote: > >> * We need an org admin. AFAIK this was done by Peff and Shawn in >> tandem last year. Would you do it again? > > I will do it again, if people feel strongly about Git being a part of > it. However, I have gotten a little soured on the GSoC experience. Not > because of anything Google has done; it's a good idea, and I think they > do a fine of administering the program. But I have noticed that the work > that comes out of GSoC the last few years has quite often not been > merged, or not made a big impact in the codebase, and nor have the > participants necessarily stuck around. This. I actually think Git should take a year off from GSoC and not participate. Consequently I will not be volunteering as backup org admin. Git has been involved since 2007. In all of that time we have had very few student projects merge successfully into their upstream project (e.g. git.git, JGit or libgit2) before the end of GSoC. Even fewer students have stuck around and remained active contributors. When I look at the amount of effort we contributors put into GSoC, I think we are misusing our limited time and resources. The intention of the GSoC program is to grow new open source developers, and increase our community of contributors. Somehow I think Git is falling well short of its potential here. This is especially true if you compare Git's GSoC program to some other equally long-running GSoC programs. > And I do not want to blame the students here (some of whom are on the cc > list :) ). They are certainly under no obligation to stick around after > GSoC ends, and I know they have many demands on their time. But I am > also thinking about what Git wants to get out of GSoC (and to my mind, > the most important thing is contributors). I agree, our students have been pretty terrific. I think the shortcomings in our GSoC program are on the mentoring side. Our program has not really had much success with keeping students active and engaged post GSoC. I see that primarily as a mentoring failure. And its one we keep repeating each year. > As far as merged code, I think part of the problem is that git is fairly > mature at this point. The most interesting projects are of a bigger > scope than a student with no experience in the code base can do in a > summer project. Maybe that means we need to do a better job of breaking > projects down into reasonably sized sub-components. Or maybe it means > the project is hitting a point of diminishing returns for GSoC. I don't > know. Let me repeat myself. I think our GSoC program has plenty of room for improvement on the mentoring side. Project scope and size is one of our most common failure modes. Resumable clone keeps winding up on the GSoC project idea list. Nobody who knows what they are talking about has any idea how to approach this feature[1]. Suggesting it to a GSoC student is just irresponsible[2]. I don't think Git's maturity is a road block for successful GSoC projects. Peff's toy to insert Lua so `git log` could do fancy formatting is an interesting one. I suspect there are still fun archeology sorts of projects that could further improve the type of data we can mine through log and blame. But touching the core file formats on disk or the wire protocol is probably far too large for a GSoC project. [1] Android's "repo" tool and its /clone.bundle hack on HTTP transports might work. Peff has talked about putting this into Git itself one day. Maybe. But its still full of a ton of shortcomings and somewhat hated by those that have to build the bundles and manage the server infrastructure. So its probably still outside of the scope of a successful GSoC project. [2] I recognize and accept my share of blame for putting it on the list a few times. > There are a few counterpoints I can think of: > > - Even though not all projects are winners, _some_ are. I see Carlos > and Ram on the cc list, two people who started as GSoC students and > stuck around. I think these interesting cases like Carlos and Ram are places where the student was able to succeed almost despite our mentoring program. I am very glad they did. > - There is also the angle that even if _Git_ doesn't benefit directly > from people sticking around, those people may float into other open > source projects and work on them. Which makes the world a better > place on the whole. Yes, sure, OK. But if Git doesn't participate in GSoC this year another org will, and this same benefit will still be had by the greater open source community. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html