Re: Google Summer of Code 2013 (GSoC13)
[corrected David Barr's address] On Monday 18 February 2013 12:42:39 Jeff King wrote: 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). Just a little comment from another student: Last year i worked on the 'remote helper for svn'. My official mentor was David Barr, but I had most interaction with Jonathan Nieder. From my point of view I wouldn't say the project was a fail. It was harder than I originally thought, yes. That happens. But we have a remote helper in master now, although its far from complete and it's development is quite stalled. (remote-testsvn) About sticking around: As you can see I read the list (I was not on CC), but not very regularly, I admit. Anyways, I'd respond to mails in CC or on IRC. During the summer I believe I learned git's development process quite well. I rerolled my main patch series 8 times until 19th of September, which is well beyond GSOC deadline. I tried to get it finished before concentrating on my studies again. If I would now continue to contribute, it would be a completely new topic (like branch mapping) and take a lot of time that I don't have during the year, where I have to push my studies forward. For a student one aspect of GSOC is also quite important: It is a cool and demanding summer job during the holidays, but it has to ramp down when the new semester starts. Anyways I think GSOC is a great idea and I enjoyed contributing to git a lot, would immediatly do it again. Keep it goin'! Thanks. Florian -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Florian Achleitner florian.achleitner2.6...@gmail.com writes: For a student one aspect of GSOC is also quite important: It is a cool and demanding summer job during the holidays, but it has to ramp down when the new semester starts. Thanks for sharing. I think an important lesson is that mentors and reviewers need to think really hard to limit the initial scope of the assignment to be not too ambitious. Starting with an ambitious goal and achieving only small first steps of them _can_ still be a good end result, but if a mentor wants to go that route, the decision to cut down the scope of an ambitous assignment needs to be made early enough to leave sufficient time to wrap up the half-done assignment in a good shape. Finishing with implementation of only the initial 30% of an unproven design, that by itself is not useful, does not help our project at all, and it does not give satisfaction to the student, either. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
On Mon, Feb 18, 2013 at 10:53 PM, Thomas Rast tr...@inf.ethz.ch wrote: * We should prepare an ideas page. Last year, Peff made one on https://github.com/peff/git/wiki/SoC-2012-Ideas [Resending the mail, because the last one failed because of inline html content] One of the proposed ideas last year - 'Use JavaScript library / framework in gitweb' I wanted to work on this project last year, but Git community didn't get a slot for the project from Google. I still worked on it and almost finished it. Sadly I never got time to polish it to merge to master. you can see some of my commits on it here. https://github.com/jaseemabid/git/commits/gitweb Detailed notes on what actually did. https://gist.github.com/jaseemabid/3218461 Gitweb is 1 huge perl script and even though it *works*, it is a poor work in 2013. The code is pretty old and is a hard thing to jump into. Quite a few here helped me to get started and it was a pretty good experience. Jakub was the mentor. Ram and John 'warthog' Hawley occasionally helped with git and general feedback back then. Andrew Sayers andrew-...@pileofstuff.org helped a lot, but he just disappeared one day. I remember John mentioning about splitting the file into smaller ones, rewriting some sections, adding more documentation etc. I'm not sure if any work was done on this. I couldn't follow the project for sometime. I will try to make some time and finish it off in the next week or so. I am having a bad schedule now between school and job, but will try my level best. -- Regards, Jaseem Abid github.com/jaseemabid -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Michael Schubert s...@schu.io writes: On 02/18/2013 06:42 PM, Jeff King wrote: 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. 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). Speaking of libgit2: Git provided the libgit2 project with a slot each of the last three GSOC. The contributions made by the former students (Disclaimer: one of them speaking) have been quite important for libgit2 and all three students are still involved. Each project was an important push towards building a new, feature complete Git library. Right, speaking of libgit2. GSoC has been very successful (as Michael, I'm also somewhat biased) for libgit2. This happens outside of the git ML so it probably hasn't gotten as much visibility here. I believe it's partly because there were still larger parts where most of the work was technical and the goal was quite clear, as git had already set the standard and expectations and the decisions had to be mostly about how to implement it in a way that makes sense for a library, rather than it living inside of git, which is not always easy, but you can experiment with different uses of it. It's also possible that part of the success was the fact that we were already acquainted with the release often and early policy, as we'd been involved with FLOSS for a while already. The current gaping hole in libgit2 is the lack of merge support, which is the last hurdle to a stable 1.0 release. There is already some work by Edward Thomson that needs to be reviewed and merged. I'm not sure that there's enough for a whole summer there, but you could throw in the review and merge of another missing feature, which is making the reference storage generic, as it currently only supports the git-compatible file-based one. There's other nice-to-have things like thin-pack support that you could use to fill up a summer, though I'm not sure that goes with the spirit of the programme. Something else that needs love is Git for Windows. I believe both git and libgit2 would benefit a lot from a project to take some parts of git that are implemented in a scripting language and port them to use libgit2. As Git for Windows needs to ship a ton of dependencies anyway, using a pre-1.0 library wouldn't be an issue and it can be used to experiment with an eventual porting of git to be one user of libgit2 rather than a completely different implementation. The more immediate benefit for Git for Windows would be less reliance on languages that are awkward to use on Windows and need their own environment. Mentoring from the libgit2 probably wouldn't be much of an issue to organise, though I'm not sure if the GfW team would have time for the part that involves its peculiarities. So there's a couple of projects that could be done with some realistic chance of being merged upstream, as they'd be technical, as long as we do tell the student to send small units of work to be reviewed often. Cheers, cmn -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Shawn Pearce spea...@spearce.org writes:
On Mon, Feb 18, 2013 at 9:42 AM, Jeff King p...@peff.net 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.
Fair enough. But I think if that's the decision (and modulo libgit2
praise, it seems to be pretty much the consensus?), we should probably
have some Idea why we are doing it?
You wrote:
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.
If that's the outset (and it's certainly true for a lot of the
projects), aren't the options (not limited to just one):
* We have some discussion about why we fail, what to do better, etc. and
hopefully also manage to clean up some old projects and get them
included. That way we can learn something from it.
* We try to look at how more successful communities are doing it
(e.g. there were some posts about how KDE bumped their student
retention rate).
* We try to mentor some projects that aren't GSoC sponsered. That way
we can hope to gain mentoring experience.
I'm not very optimistic about any of these, as:
- There weren't any in-depth discussions post-GSoC to analyze what went
wrong.
- Contributor time is so limited that we're usually short on reviews.
Adding mentoring for the sake of trying it to duties isn't very
promising.
Thus I'm a bit afraid that after a year off, we won't have learned
anything new. To the contrary, some previous mentors/students will
inevitably have disappeared into the mists of time, and with them their
experience. Unless we do something about it, next year we'll be in an
_even worse_ position than this year.
I'm mildly pessimistic about doing something over the list, but
perhaps we can have an extended discussion at git-merge provided enough
of you show up there? I can try to prepare some material.
(Maybe we should all make a bunch of clones of ourselves. We can put
one copy each into a room so they can figure out GSoC, and have another
group doing our favorite git hacking while we're at it.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Hi, On Wed, Feb 20, 2013 at 7:50 AM, Shawn Pearce spea...@spearce.org wrote: On Mon, Feb 18, 2013 at 9:42 AM, Jeff King p...@peff.net 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 think it is ok if the code doesn't make a big impact in the code base and it is ok too if the participants don't stuck around. Of course I would love both of these things to happen, but we have to be realistic and just stop expecting it. 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. I don't think so, at least not for me. I feel happy to mentor or co-mentor GSoC student and I don't think I would work much more on git these days if git was not participating to the GSoC. 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. I don't quite agree with this. My experience has been the following: - 2008: the student I co-mentored did pretty well though he didn't send to the list his patch series early enough. So there was some mentoring failure, but anyway the student stuck around for 9 months and managed to get 53 commits merged. - 2009: if I remember well, it was decided to have only 2 GSoC student that year, and that 5 people would co-mentor both of them together. One of the student did nearly nothing. The other one sent his patch series too late to the list. My opinion is that he relied too much on the people mentoring him and he worked on something that was difficult to merge. - 2010: the student I co-mentored stopped working 3 weeks before the mid-term evaluation despite some warnings from me and Peff, and he had not been doing much a few weeks before that, so we decided to fail him at the mid term evaluation. - 2011: I was lucky to mentor Ram who did well and is still around. So my opinion is that we have some students who are just not doing enough (2 out of 5). Then we have some good students, 2 out of 5 who could sometimes do better if we insisted more on submitting earlier to the mailing list. And we have a few students (1 out of 5) who work difficult to merge projects and who could do better if we insisted more on submitting earlier to the mailing list. So my conclusions are: - it's quite often going well or well enough - when it's not going well often the student is responsible - yes, we could improve mentoring by providing better projects and insisting even more on submitting earlier [...] - 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. The greater open source community benefits a lot these days when Git is improved and get new contributors, as git is now by far the most widely used version control system in the open source community. So my opinion is that we should have has many GSoC student as we can
Re: Google Summer of Code 2013 (GSoC13)
Christian Couder christian.cou...@gmail.com writes: - yes, we could improve mentoring by providing better projects and insisting even more on submitting earlier A few words about my experience, not with GSoC, but with school projects (I've been proposing a few students in Ensimag to contribute to Git each year since 2010). Last year, we've been using Scrum, and the definition of done was a very helpful tool. In Scrum, nothing is ever half done, it is either done or not done. Out of a 3 weeks project, the definition of done was initially ready to be sent to the list, then sent to the list, no major criticism in reviews the second week, and sent to the list, no more objections in reviews the last week. At the beginning of each week (sprint in Scrum), students were commiting to a list of tasks, and at the end of each week, we evaluated how many were done. This encouraged students to avoid overcommiting and send patches early. Some of them validated nothing at all the first week: they hadn't realized the distance between their notion of clean working code and the one on this list, but at least they realized it early enough. Of course, even with that, I had to continue the work to push it to master for some patch series, and discard some series that were basically not there. Having several small projects instead of one big was very important. I'm not sure how the GSoC would feel about a list of small tasks instead of one ambitious project however. My main disappointment is that I never managed to keep students in the community past the end of the project. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
On 02/18/2013 06:42 PM, Jeff King wrote: 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. 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). Speaking of libgit2: Git provided the libgit2 project with a slot each of the last three GSOC. The contributions made by the former students (Disclaimer: one of them speaking) have been quite important for libgit2 and all three students are still involved. Each project was an important push towards building a new, feature complete Git library. Thank you! http://libgit2.github.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Jonathan Nieder wrote: Ramkumar Ramachandra wrote: The short undiplomatic version of that is that our mentors suck (I'm not pointing fingers, but that's what I infer from failing projects). Hold on a second. I'm not remembering such a grim outcome with 100% failure from prior summers of code as you're describing. Before I start beating myself up, I guess I'd like a little more information --- is there some specific project or statistic that you're thinking of that brings you to that conclusion? In retrospect, I might have been unnecessarily harsh there. One of the main measures of a mentor's success, in my opinion, is having his student stick around after the Summer of Code: the mentor is the student's primary link to the community. There have been 4~5 students every year, times 6 years (is that how long we've been participating?). How many of those students have felt part of the community? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Junio C Hamano wrote: Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: ... I think the real issue is everybody in the GSoC mentor candidate pool grossly underestimates the scope of suggested projects, does not encourage students to send early drafts to the public from the beginning, and perhaps overestimates the ability of total beginners. After seeing my index-thing is too big in scope warning repeatedly ignored for the last year's GSoC, I am not very hopeful unless the attitude towards GSoC and its students drastically changes on our mentors' end. The short undiplomatic version of that is that our mentors suck (I'm not pointing fingers, but that's what I infer from failing projects). I was conflating between people who add suggested project and who act as mentors. I do not think mentors are primarily responsible for bad suggested projects. Why do mentors pick badly sketched-out projects to mentor? They're free to pick anything they want/ propose what they want. Our mentors may be wonderful but I do not have enough evidence to judge either way. They are mostly student-facing and I as a bystander to GSoC process didn't see much of their involvement in their students' work---maybe that is how it is supposed to work, maybe not. The only failing of them observable from my point of view was that we repeatedly saw the initial round of patches come very late. Ideally, the initial round of patches should come in well before the GSoC even starts, I think (the initial round might just be doing some minor surrounding work though). I propose that we have one thread for every proposal where we can all discuss the implementation outline- this will serve as authoritative source of information for students, and for picking mentors (the people who contribute most to the discussion). Students should be matched with mentors on an individual basis. You are being unreasonable and/or unrealistic. A topic that needs a large discussion thread to pre-discuss design and outline by many existing members of community and mentor candidates is a sure sign that the topic is too big for a beginner. A topic that needs only a small enough discussion thread on the other hand will come to a polished conclusion before even the student shows up. I that case, projects like inotify support that Duy suggested in a nearby thread are not realistic candidates. No, I wouldn't like huge discussion threads on each proposal either: but a ~10 email thread with everyone's thoughts on it would be useful, I think. If the size of the thread exceeds a certain threshold, the project is deemed un-doable automatically. This is exactly why I suggested doable as a private, at most two-weekend hack by an experienced as a quick and dirty way to measure the size of a project. Yes, that's a good measure. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra artag...@gmail.com writes:
Jonathan Nieder wrote:
Ramkumar Ramachandra wrote:
The short undiplomatic version of that is that our mentors suck (I'm
not pointing fingers, but that's what I infer from failing projects).
Hold on a second. I'm not remembering such a grim outcome with 100%
failure from prior summers of code as you're describing. Before I
start beating myself up, I guess I'd like a little more information
--- is there some specific project or statistic that you're thinking
of that brings you to that conclusion?
In retrospect, I might have been unnecessarily harsh there.
One of the main measures of a mentor's success, in my opinion, is
having his student stick around after the Summer of Code: the mentor
is the student's primary link to the community. There have been 4~5
students every year, times 6 years (is that how long we've been
participating?). How many of those students have felt part of the
community?
In defense of Thomas, whose project was mentioned earlier as a prime
example of something that is too big:
He's in fact still working on the index-API angle, as part of a thesis
at university.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Jeff King wrote: On Tue, Feb 19, 2013 at 01:15:49AM +0530, Ramkumar Ramachandra wrote: Take what I'm about to say with a pinch of salt, because I've never mentored. Mentors often don't provide much technical assistance: students should just post to the list with queries, or ask on #git-devel. Mentors serve a different purpose; their primary responsibility, in my opinion, is to teach the student a sustainable productive workflow. This means: profiling them to figure out where they're losing out. Do they have the habit of: - posting to the list regularly? - CC'ing the right people? - iterating quickly after reviews? - using gdb efficiently to quickly understand parts? - using git efficiently for the rebase/ patch workflow? I think you are spot-on. Those are the things that students need to learn to do, and what mentors should be pushing them towards. But it seems like we have the same problems with it year after year, and I know mentors have worked on it. I'm not sure where the problem is. I essentially have a couple of suggestions: - Be more thorough about discussing proposals; pick mentors from those who are deeply involved in the discussion, and are interested in the student. - Increase the visibility of every GSoC project in the community. Like I suggested earlier, a set of GSoC branches in-tree would be a great start: it's easy to go through the `log`, and tell if the student has been idle for a while. We can put up links to the GitHub graphs for each of these branches. I very much agree with you here. One problem is that those smaller projects often do not sound as grand or as interesting, and so students do not propose them. We have to work with the applicants we get. We have to post well-crafted proposals like this to pique their interest. True. I think we can bear some of the blame in the proposal writing. But if you look at the applications each year, they tend to cluster around one or two projects, and most projects get no hits at all. It could be because they're badly written. But I think it is also that they are not in areas that are as flashy (and the flashiness often correlates with complexity). We need to collaborate on proposal writing, I think (which is why I suggested one-thread-per-proposal in a different email). In the past, it has mostly been one person writing the entire thing. There is one easy way to fight spam: don't expose a web-based editing interface at all. It's mainly going to be maintained by the community, and we're all much more comfortable in our editors and git. We can give the regulars direct commit access and ask the rest to submit pull requests. Make it cost pennies, so any of us can easily afford it: just a cheap domain, DNS, and static HTML hosting. I'd be totally fine with that. You'd need to pick a static generator framework (I don't think it is a good idea for everybody to be writing raw html). I suspect kernel.org would be happy to host the static pages, but if not, GitHub can pick up the hosting tab (and we could probably do it as a subdomain under git-scm.com, too, if people want). Ofcourse. Nobody wants to write raw HTML. Additionally, I'd love it if we could post new posts via email, since we already have the habit of writing emails. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Thomas Rast tr...@inf.ethz.ch writes: In defense of Thomas, whose project was mentioned earlier as a prime example of something that is too big: He's in fact still working on the index-API angle, as part of a thesis at university. That is probably a good indicator that it was too big for a summer student. It also is good to hear that the topic is being looked at ;-). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra artag...@gmail.com writes: I was conflating between people who add suggested project and who act as mentors. I do not think mentors are primarily responsible for bad suggested projects. Why do mentors pick badly sketched-out projects to mentor? They're free to pick anything they want/ propose what they want. I've had an impression that these Wiki entries were written by people with names of mentors (who are different from the proposers) already assigned to them, and if an unfortunate student picked an unrealistic one, these mentor candidates were too nice to push back and decline, saying it is unrealistic, leaving the student and proposal without any mentor. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@inf.ethz.ch writes:
In defense of Thomas, whose project was mentioned earlier as a prime
example of something that is too big:
He's in fact still working on the index-API angle, as part of a thesis
at university.
That is probably a good indicator that it was too big for a summer
student. It also is good to hear that the topic is being looked at
;-).
Not really: the API angle was never part of the proposal. The timeline
was [1 if you have access]:
24/04 - 01/05: Document the new index format.
02/05 - 11/05: Create a converter of the old index format to the new format.
12/05 - 18/06: Parse the index from disk to the current in-memory format. The
old index format shall still be readable.
19/06 - 09/07: Implement the re-reading of a single record, if the crc32
doesn't
match (Meaning the record has been changed under the reader).
10/07 - 21/07: Map the current internal structure to the new index format.
22/07 - 31/07: Change the current in-memory structure to keep track of the
changed files.
01/08 - 13/08: Write the index to disk in both the old and the new format
depending on the choice of the user and make sure only the changed parts are
really written to disk in the new format.
11/08 - 13/08: Test the new index and profile the gains compared to the old
format.
/* Development work will be a bit slower from 18/06 to 21/07 because at my
* University there are exams in this period. I probably will only be able to
* work half the hours. I'll be back up to full speed after that. */
I think this case is somewhat symptomatic for one possible cause of
dragged-out non-inclusions _after_ GSoC: there's a certain scope creep
caused by striving for the perfect, long-term maintainable code.
The solution IMHO is to _both_ recognize such possibilities for scope
creep, and cut down the proposals to a size where a student has a
reasonable chance of achieving the code quality required for inclusion.
(The latter option has been mentioned a few times, but I wanted to make
people aware that the scope creep is happening, too.)
Footnotes:
[1]
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/tgummerer/1
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
On Mon, Feb 18, 2013 at 9:02 PM, Jens Lehmann jens.lehm...@web.de wrote: Am 18.02.2013 20:34, schrieb Jonathan Nieder: That said, I won't have time to mentor a project on my own. It takes a lot of time (or luck, to get the student that doesn't need mentoring). That's my experience too. Also I think it really makes sense to have a co-mentor so you can balance the load a bit. I'd be happy to help on a project with 1 or 2 co-mentors. Same here. I am ok to be mentor or co-mentor. Thanks, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
On Mon, Feb 18, 2013 at 9:42 AM, Jeff King p...@peff.net 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Google Summer of Code 2013 (GSoC13)
Hi,
Google announced the 2013 incarnation of the Google Summer of Code
program on Feb 11:
http://www.google-melange.com/gsoc/homepage/google/gsoc2013
Git has taken part in previous years, so I figure somebody should get
the ball rolling again! The following items need to be sorted out:
* We need an org admin. AFAIK this was done by Peff and Shawn in
tandem last year. Would you do it again?
* We should prepare an ideas page. Last year, Peff made one on
https://github.com/peff/git/wiki/SoC-2012-Ideas
I couldn't edit it there over git access[1], so I made a clone in my
github wiki:
https://github.com/trast/git/wiki/SoC-2013-Ideas
I'll volunteer to manage that wiki[2]. Please either edit it
directly, or send me patches or pull requests. I won't really have
time to properly review them, but I'll do my best to merge everything.
* Naturally that ideas page is a bit stale now, and three projects
shorter. Please propose new ideas and refresh or delete the old ones!
In particular some projects spawned long discussions on the list, and
the results of those discussions should be integrated to avoid deja
vus.
* We should have a pool of mentors and rough mentor-project matchings.
I gathered a -- certainly incomplete -- list of previous mentors and
students in the Cc field; maybe some of you are interested again? If
so, propose your own ideas and/or list yourself in the proposed
mentors for some existing projects. (I cleared all those fields for
now.)
* Even if you don't want to mentor, you can still contribute by helping
with discussing and ranking proposals, especially immediately before
and after the project submission deadline (May 3).
If we want to participate again, we need to get together an org
application until *March 29* 19:00 UTC, and it won't exactly hurt to
have the ideas page settled until then too.
It would be really nice if we could do this again, I think GSoC is a
great opportunity both for Git and the involved students.
Cheers
Thomas
Footnotes:
[1] That's a bit silly really, since I *can* edit it via the web
interface. Peff, perhaps you can get that fixed?
[2] Unless Peff wants to take it over again? You could just pull it
from the git version, it's based on your history.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
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. 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). 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. 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. - 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. So I don't know. Those are just some things that have been floating around in my head. Feel free to ignore or discuss. But thanks for getting the ball rolling, Thomas. If we are going to do it, sooner is better, and if we aren't, then we should probably do so consciously, and not just miss the deadline accidentally. :) * We should prepare an ideas page. Last year, Peff made one on https://github.com/peff/git/wiki/SoC-2012-Ideas I couldn't edit it there over git access[1], so I made a clone in my github wiki: [...] [1] That's a bit silly really, since I *can* edit it via the web interface. Peff, perhaps you can get that fixed? Ugh, I would have to write ruby code to fix that. I'll try to trick somebody else here into fixing it. :) [2] Unless Peff wants to take it over again? You could just pull it from the git version, it's based on your history. I think it is as good on your repo as on mine. The kernel.org wiki is also up, and the github/peff/git one was supposed to be temporary. But I really hate any wiki that I cannot edit with vim. I guess we need to have a discussion as a group about where the official wiki should live, and it should go there (I can also put it at github/git/git, which is a more sane place; but I do not want to compete with kernel.org's wiki unless there is community consensus that we are moving). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Thomas Rast tr...@inf.ethz.ch writes:
* We should prepare an ideas page[...]
https://github.com/trast/git/wiki/SoC-2013-Ideas
From where I'm currently sitting, I won't have the time to mentor this
year. So my two earlier proposals are essentially up for grabs:
1. Improving parallelism in various commands
-
Git is mostly written single-threaded, with a few commands having
bolted-on extensions to support parallel operation (notably git-grep,
git-pack-objects and the core.preloadIndex feature).
We have recently looked into some of these areas and made a few
optimizations, but a big roadblock is that pack access is entirely
single-threaded. The project would consist of the following steps:
* In preparation (the half-step): identify commands that could
benefit from parallelism. `git grep --cached` and `git grep
COMMIT` come to mind, but most likely also `git diff` and `git log
-p`. You can probably find more.
* Rework the pack access mechanisms to allow the maximum possible
parallel access.
* Rework the commands found in the first step to use parallel pack
access if possible. Along the way, document the improvements with
performance tests.
The actual programming must be done in C using pthreads for obvious
reasons. At the very least you should not be scared of low-level
programming. Prior experience and access to one or more multi-core
computers is a plus.
This one is probably still a contender. However, it might be worth
first looking into whether using libgit2 for pack reading would be
easier and faster, since it is written to be reentrant from the ground
up.
2. Improving the `git add -p` interface
The interface behind `git {add|commit|stash|reset} {-p|-i}` is shared
and called `git-add--interactive.perl`.This project would mostly
focus on the `--patch` side, as that seems to be much more widely
used; however, improvements to `--interactive` would probably also be
welcome.
The `--patch` interface suffers from some design flaws caused largely
by how the script grew:
* Application is not atomic: hitting Ctrl-C midway through patching
may still touch files.
* The terminal/line-based interface becomes a problem if diff hunks
are too long to fit in your terminal.
* Cannot go back and forth between files.
* Cannot reverse the direction of the patch.
* Cannot look at the diff in word-diff mode (and apply it normally).
Due to the current design it is also pretty hard to add these features
without adding to the mess. Thus the project consists of:
* Come up with more ideas for features/improvements and discuss them
with users.
* Cleanly redesigning the main interface loop to allow for the above
features.
* Implement the new features.
As the existing code is written in Perl, that is what you will use for
this project.
This has already featured twice, and resulted in proposals that were
insufficiently advanced and too little work for a GSoC. If nobody feels
like extending it to a bigger project, I'll just scrap it.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Thomas Rast wrote: 2. Improving the `git add -p` interface * The terminal/line-based interface becomes a problem if diff hunks are too long to fit in your terminal. I don't know if it's worth coming up with another interface. The best solution for this is editor integration, in my opinion. I use Magit mostly for just the graphical staging/ unstaging. There's also a Fugitive.vim for vim. * Cannot look at the diff in word-diff mode (and apply it normally). Yes, this is a major limitation that would be nice to fix. Also: Having to figure out, heuristically, when to actually turn it on might be a worthwhile feature, especially for services like GitHub. As the existing code is written in Perl, that is what you will use for this project. I don't know- is Perl a possible deterrent? Won't getting a word-diff to apply involve C work though? (patching builtin/apply.c?) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
On Mon, 18 Feb 2013 18:46:05 +0100, Thomas Rast tr...@student.ethz.ch said: ThomasThe actual programming must be done in C using pthreads Thomas for obvious reasons. Are there obvious reasons OpenMP would not be enough to do the job? It looks like a trade-off between the code readability portability versus the real expressiveness of what parallelism control details are needed. -- Ronan KERYELL|\/ Phone: +1 650 386 6482 SILKAN Wild Systems |/) 4962 El Camino Real #201 Kronan.kery...@silkan.com Los Altos, CA 94022 |\ skype:keryell USA | \ http://silkan.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote: I'll be frank here. I think the main reason for a student to stick around is to see more of his code hit `master`. I think it is absolutely essential to get students constantly post iteration after iteration on the list. It would be nice to get them connected with 2~3 people in the community who will follow their progress and pitch in everytime they post an iteration. It might also make sense to stage their work in the main tree (a gsoc/ namespace?), so we can just checkout to their branch to demo what they've done. I agree. One of the main problems with GSoC projects is that the student goes away and works for a while, and then at the end does not necessarily have something mergeable. That is not how regular contributors work. They post works in progress, get feedback, and iterate on ideas. They break work into easily digestable and reviewable chunks. So maybe the mentors should be focusing more on that than on actual code problems. Also, we need more projects that will scratch everyday itches. A collection of related tiny features might not be a bad idea. Often, we risk erring on the side of too-big-for-one-summer when it comes to specifying projects. What's the harm of including something estimated to take 80% of a summer? I very much agree with you here. One problem is that those smaller projects often do not sound as grand or as interesting, and so students do not propose them. We have to work with the applicants we get. On a related note, I don't like our Wiki. It's down half the time, and it's very badly maintained. I want to write content for our Wiki from the comfort of my editor, with version control aiding me. And I can't stand archaic WikiText. Agreed on all of those points. Putting the Wiki on GitHub fixes that. But it means contributors need to have a GitHub account. On the other hand, I think kernel.org wiki contributors need an account these days? And GitHub is putting some active effort into finding and killing spammy accounts, which might keep wiki spam down (I do not pay too much attention to those efforts, but on kernel.org, it is mostly up to the Git community to do it ourselves). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Hi, Jeff King wrote: 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. I think that if we can commit enough time to mentor well it's worthwhile. Even such a negative result is useful, since it can teach us how good or poor we are at bringing new contributors in and what parts of that process need more work. That said, I won't have time to mentor a project on my own. It takes a lot of time (or luck, to get the student that doesn't need mentoring). I'd be happy to help on a project with 1 or 2 co-mentors. Some potential projects (unfiltered --- please take them with a grain of salt): - cross-compilable git - incorporation of the cgit web interface, or formalizing a subset of libgit.a to export as a stable library to it - merging the gitweb-caching fork - moving forward on a project that was the subject of a previous gsoc project: line-level logging, rebase --interactive on top of sequencer, usable svn remote helper - collapsable --first-parent history in gitk http://bugs.debian.org/61 - drag-and-drop cherry-pick in gitk - a sub-library of code shared with libgit2 (might be hard because our notions of strings are different :(). - assimilating the distro builds: make deb-pkg, make rpm-pkg, etc along the same lines as the linux kernel's script/package/, to help people get recent git installed when they want it - please cherry-pick this before testing that notes for less scary bisecting - collaborative notes editing: fix the default notes refspec, make sure the notes pull workflow works well and is documented well, offer an easy way to hide private notes after the fact without disrupting public history Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra artag...@gmail.com writes:
[corrected David Barr's email address]
Jeff King wrote:
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).
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.
I'll be frank here. I think the main reason for a student to stick
around is to see more of his code hit `master`. I think it is
absolutely essential to get students constantly post iteration after
iteration on the list. It would be nice to get them connected with 2~3
people in the community who will follow their progress and pitch in
everytime they post an iteration. It might also make sense to stage
their work in the main tree (a gsoc/ namespace?), so we can just
checkout to their branch to demo what they've done.
I agree, but I think there's an additional component. Consider the 'log
-L' feature. It's fairly workable, and I merge it in my own builds and
use it, but there were and are two main issues:
* The initial work by Bo was not in shape to be included, mostly because
the code was too convoluted in the parts that process line ranges.
* The last version I posted was held up because there's _in principle_ a
better way to do things, but it requires major refactorings of
existing code.
I'm not going to try to discuss away the first one; it's also a failure
of myself as mentor. However, as far as incomplete work goes, I think
the latter item is fairly symptomatic. We underestimate the amount of
work required to polish and reroll a submission that a student would
deem sufficiently working for inclusion, fixes to be done later.
So I agree with your suggestion:
What's the harm of including something estimated to take 80% of a
summer?
Maybe even less than 80%.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Jeff King wrote: On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote: I'll be frank here. I think the main reason for a student to stick around is to see more of his code hit `master`. I think it is absolutely essential to get students constantly post iteration after iteration on the list. It would be nice to get them connected with 2~3 people in the community who will follow their progress and pitch in everytime they post an iteration. It might also make sense to stage their work in the main tree (a gsoc/ namespace?), so we can just checkout to their branch to demo what they've done. I agree. One of the main problems with GSoC projects is that the student goes away and works for a while, and then at the end does not necessarily have something mergeable. That is not how regular contributors work. They post works in progress, get feedback, and iterate on ideas. They break work into easily digestable and reviewable chunks. So maybe the mentors should be focusing more on that than on actual code problems. Take what I'm about to say with a pinch of salt, because I've never mentored. Mentors often don't provide much technical assistance: students should just post to the list with queries, or ask on #git-devel. Mentors serve a different purpose; their primary responsibility, in my opinion, is to teach the student a sustainable productive workflow. This means: profiling them to figure out where they're losing out. Do they have the habit of: - posting to the list regularly? - CC'ing the right people? - iterating quickly after reviews? - using gdb efficiently to quickly understand parts? - using git efficiently for the rebase/ patch workflow? Also, we need more projects that will scratch everyday itches. A collection of related tiny features might not be a bad idea. Often, we risk erring on the side of too-big-for-one-summer when it comes to specifying projects. What's the harm of including something estimated to take 80% of a summer? I very much agree with you here. One problem is that those smaller projects often do not sound as grand or as interesting, and so students do not propose them. We have to work with the applicants we get. We have to post well-crafted proposals like this to pique their interest. On a related note, I don't like our Wiki. It's down half the time, and it's very badly maintained. I want to write content for our Wiki from the comfort of my editor, with version control aiding me. And I can't stand archaic WikiText. Agreed on all of those points. Putting the Wiki on GitHub fixes that. But it means contributors need to have a GitHub account. On the other hand, I think kernel.org wiki contributors need an account these days? And GitHub is putting some active effort into finding and killing spammy accounts, which might keep wiki spam down (I do not pay too much attention to those efforts, but on kernel.org, it is mostly up to the Git community to do it ourselves). No, I'm against using the GitHub Wiki for neutrality reasons. There is one easy way to fight spam: don't expose a web-based editing interface at all. It's mainly going to be maintained by the community, and we're all much more comfortable in our editors and git. We can give the regulars direct commit access and ask the rest to submit pull requests. Make it cost pennies, so any of us can easily afford it: just a cheap domain, DNS, and static HTML hosting. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Ronan Keryell ronan.kery...@silkan.com writes:
On Mon, 18 Feb 2013 18:46:05 +0100, Thomas Rast tr...@student.ethz.ch
said:
ThomasThe actual programming must be done in C using pthreads
Thomas for obvious reasons.
Are there obvious reasons OpenMP would not be enough to do the job?
It looks like a trade-off between the code readability portability
versus the real expressiveness of what parallelism control details are
needed.
Except for the added dependency you mean?
I'm not sure exactly what the capabilities of OpenMP are that would help
here, but most likely it would work. It wouldn't really change the
amount of work needed, though, since the main work is in shuffling
around the existing code paths to be amenable to parallel access in the
first place. A dumb parallelization (i.e., just locking around all
shared structures) POC yielded very little speedup because of lock
contention.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra artag...@gmail.com writes:
* Cannot look at the diff in word-diff mode (and apply it normally).
[...]
Also: Having to figure out, heuristically, when to actually turn it on
might be a worthwhile feature, especially for services like GitHub.
Actually that's a pretty cute idea of its own. You could call it
--smart-diff or some such, and define its output as whatever diff
format git thinks would be appropriate.
And given the current state of diff pipeline refactorization, the effort
is probably on the order of magnitude of a GSoC...
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra wrote: Take what I'm about to say with a pinch of salt, because I've never mentored. Mentors often don't provide much technical assistance: students should just post to the list with queries, or ask on #git-devel. Mentors serve a different purpose; their primary responsibility, in my opinion, is to teach the student a sustainable productive workflow. I basically agree. One of the most important jobs of mentors is to make sure there are people available to provide prompt technical assistance, hopefully before the project begins. [...] - using gdb efficiently to quickly understand parts? Oh, dear. I hope not. ;-) Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Am 18.02.2013 20:45, schrieb Thomas Rast: Ramkumar Ramachandra artag...@gmail.com writes: What's the harm of including something estimated to take 80% of a summer? Maybe even less than 80%. I didn't regret at all having split the summer's topic I mentored into smaller pieces. That made it easy to post patches to the list rather early (and IIRC some of them hit master before the end of the GSoC). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Am 18.02.2013 20:34, schrieb Jonathan Nieder: That said, I won't have time to mentor a project on my own. It takes a lot of time (or luck, to get the student that doesn't need mentoring). That's my experience too. Also I think it really makes sense to have a co-mentor so you can balance the load a bit. I'd be happy to help on a project with 1 or 2 co-mentors. Same here. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Jonathan Nieder wrote: Hi, Jeff King wrote: 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. I think that if we can commit enough time to mentor well it's worthwhile. Even such a negative result is useful, since it can teach us how good or poor we are at bringing new contributors in and what parts of that process need more work. The point is that we must be willing to spend time learning what went wrong the previous summer, and how to improve upon it. There's no point in doing a lather-rinse-repeat after many consecutive failures. Some potential projects (unfiltered --- please take them with a grain of salt): - cross-compilable git Why, exactly? Git for embedded devices? - incorporation of the cgit web interface, or formalizing a subset of libgit.a to export as a stable library to it I didn't understand this: you want cgit in-tree? - moving forward on a project that was the subject of a previous gsoc project: line-level logging, rebase --interactive on top of sequencer, usable svn remote helper I can't see a roadmap for gradually phasing out `rebase -i` as more and more of its functionality is built into the sequencer. Would you start by using `cherry-pick --continue` in the special case of consecutive `pick` or `revert` operations (yuck)? The sequencer currently has a continuation logic that we can leverage, but how will it call out to shell functions to do specific tasks (like `fixup`, which is not yet implemented)? Really, the only way I see is to duplicate the functionality of `rebase -i` in C, and throw away the shell script when we're sure we're done. For usable svn remote helper, the major TODO is a git - svn bridge. My previous effort (which was a long time) was stalled because we needed a way to persist blobs of text referenced by marks, and retrieve them on demand. Building this bridge is hard enough already, and I think we should just focus on an independent git - svn bridge to put into contrib/svn-fi as a deliverable. It doesn't have to have anything to do with remote helpers at all. - drag-and-drop cherry-pick in gitk You expect someone to write Tcl/Tk today? Do a `git log gitk-git/` and tell me how many people are writing it. - a sub-library of code shared with libgit2 (might be hard because our notions of strings are different :(). - assimilating the distro builds: make deb-pkg, make rpm-pkg, etc along the same lines as the linux kernel's script/package/, to help people get recent git installed when they want it Overkill. I just symlink to bin-wrapper/git from a place high up in my $PATH. If anything, we should be making it easier for ourselves to run different versions of git right from $HOME, much like rbenv. System-wide installs are taken care of by the distribution package managers, and I doubt they need any help from us. - collaborative notes editing: fix the default notes refspec, make sure the notes pull workflow works well and is documented well, offer an easy way to hide private notes after the fact without disrupting public history I personally don't care for notes much, because I can't see practical usecases. I'd much rather fix something that's much more widely used and broken: submodules. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
On Tue, Feb 19, 2013 at 02:14:54AM +0530, Ramkumar Ramachandra wrote: - assimilating the distro builds: make deb-pkg, make rpm-pkg, etc along the same lines as the linux kernel's script/package/, to help people get recent git installed when they want it Overkill. I just symlink to bin-wrapper/git from a place high up in my $PATH. If anything, we should be making it easier for ourselves to run different versions of git right from $HOME, much like rbenv. System-wide installs are taken care of by the distribution package managers, and I doubt they need any help from us. This is not related to GSoC anymore, but I think handling multiple versions is already pretty easy. You can just install to $HOME/local/git/$TAGNAME or similar, and then symlink the bin/git binary from there into your PATH as git.$TAGNAME (e.g., git.v1.7.8). Git already takes care of the messy bits, like making sure sub-programs are invoked from the same git version. I already do this automagically with this script: https://github.com/peff/git/blob/meta/install/prefix I just set prefix in the Makefile based on the script, and when I make install tags or topic branches, they go to the right place (and the links script in the same directory maintains the symlinks for me). I never bothered to even submit those scripts to contrib, because I figured they were so specific to my setup, and to keeping dozens of git versions around (when debugging, it's nice to be able to check an old version's behavior without even having to build it). Of course that has nothing to do with Jonathan's proposal. I do agree that it is pretty straightforward to just put $BUILD_DIR/bin-wrappers in your PATH and be done. I guess that doesn't cover manpages, though (but Real Programmers just read the source anyway, right?). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Potential GSoC13 projects (Re: Google Summer of Code 2013 (GSoC13))
Ramkumar Ramachandra wrote: Jonathan Nieder wrote: - cross-compilable git Why, exactly? Git for embedded devices? My personal motivation would be building Git for Windows while spending as little time on Windows as possible. People deploying git to 32-bit x86, 64-bit x86, and ARM (think ARM laptops) might also find it handy. - incorporation of the cgit web interface, or formalizing a subset of libgit.a to export as a stable library to it I didn't understand this: you want cgit in-tree? Yes, or a stable API that cgit out-of-tree can use. - moving forward on a project that was the subject of a previous gsoc project: line-level logging, rebase --interactive on top of sequencer, usable svn remote helper I can't see a roadmap for gradually phasing out `rebase -i` as more and more of its functionality is built into the sequencer. It's a break-the-world thing. rebase -i --experimental. [...] For usable svn remote helper, the major TODO is a git - svn bridge. There are other major TODOs, too. [...] - drag-and-drop cherry-pick in gitk You expect someone to write Tcl/Tk today? Sure, why not? Tcl is not actually too unpleasant of a language. Maybe it has a prerequisite, though: - modular gitk (splitting gitk into digestible pieces) [...] - assimilating the distro builds: [...] Overkill. My itch is that it would let me send packaging patches to the list and get the usual high-quality feedback. Oh well. ;-) [...] - collaborative notes editing: fix the default notes refspec, make sure the notes pull workflow works well and is documented well, offer an easy way to hide private notes after the fact without disrupting public history I personally don't care for notes much, because I can't see practical usecases. Are you sure that's not because of the poor current state of collaborative notes editing? Some example use cases: - marking regressions discovered later, to warn people bisecting or cherry-picking - matching up to corresponding commits in another repository - link to corresponding mailing list discussion, blog post, or related patches - a wiki-like document storing review comments - marking which CVE this fixes, once the CVE number has been allocated - a tour of the project for new contributors, using explanatory notes that end with a mention the next commit to look at I'm not married to the current implementation, but I think the basic idea of git notes is a promising feature that could use some polish. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
On Tue, Feb 19, 2013 at 01:15:49AM +0530, Ramkumar Ramachandra wrote: Take what I'm about to say with a pinch of salt, because I've never mentored. Mentors often don't provide much technical assistance: students should just post to the list with queries, or ask on #git-devel. Mentors serve a different purpose; their primary responsibility, in my opinion, is to teach the student a sustainable productive workflow. This means: profiling them to figure out where they're losing out. Do they have the habit of: - posting to the list regularly? - CC'ing the right people? - iterating quickly after reviews? - using gdb efficiently to quickly understand parts? - using git efficiently for the rebase/ patch workflow? I think you are spot-on. Those are the things that students need to learn to do, and what mentors should be pushing them towards. But it seems like we have the same problems with it year after year, and I know mentors have worked on it. I'm not sure where the problem is. I very much agree with you here. One problem is that those smaller projects often do not sound as grand or as interesting, and so students do not propose them. We have to work with the applicants we get. We have to post well-crafted proposals like this to pique their interest. True. I think we can bear some of the blame in the proposal writing. But if you look at the applications each year, they tend to cluster around one or two projects, and most projects get no hits at all. It could be because they're badly written. But I think it is also that they are not in areas that are as flashy (and the flashiness often correlates with complexity). No, I'm against using the GitHub Wiki for neutrality reasons. Fair enough. I have the same reservations. There is one easy way to fight spam: don't expose a web-based editing interface at all. It's mainly going to be maintained by the community, and we're all much more comfortable in our editors and git. We can give the regulars direct commit access and ask the rest to submit pull requests. Make it cost pennies, so any of us can easily afford it: just a cheap domain, DNS, and static HTML hosting. I'd be totally fine with that. You'd need to pick a static generator framework (I don't think it is a good idea for everybody to be writing raw html). I suspect kernel.org would be happy to host the static pages, but if not, GitHub can pick up the hosting tab (and we could probably do it as a subdomain under git-scm.com, too, if people want). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra artag...@gmail.com writes: [corrected David Barr's email address] Jeff King wrote: 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). 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. Also, we need more projects that will scratch everyday itches. A collection of related tiny features might not be a bad idea. Often, we risk erring on the side of too-big-for-one-summer when it comes to specifying projects. What's the harm of including something estimated to take 80% of a summer? I think the real issue is everybody in the GSoC mentor candidate pool grossly underestimates the scope of suggested projects, does not encourage students to send early drafts to the public from the beginning, and perhaps overestimates the ability of total beginners. After seeing my index-thing is too big in scope warning repeatedly ignored for the last year's GSoC, I am not very hopeful unless the attitude towards GSoC and its students drastically changes on our mentors' end. We have solicited suggested projects entries via wiki in the past, letting anybody to put anything there, and I think that was a major source of our past failures. The practice lets irresponsive people who think they know what they are talking about to place unrealistic pie-in-the-sky there. I wonder if we can somehow come up with a way to limit them to realisitic ones in a sane way. One possibility may be to require the proposer to already have an 80% answer, not to be shared with students. A project that a GSoC student who is not familiar with our codebase and culture (e.g. our no regressions policy and requiring solid transition plan for disruptive changes) is expected to finish in a summer should not be bigger than what a mentor familiar with our project can do a rough outline design and implementation as a two-weekend hack at most, I think. Such a requirement on the proposer's end may be a reasonable sanity check to make sure we do not suggest sure-to-fail projects to the students. It is ironic that I have to point out that the best let's get students exposed to the OSS process using Git community's reviewing bandwidth last year from my point of view happened outside the GSoC. Matthieu's school projects were not structured to the GSoC standard (they assigned multiple students working together on each topic), but the size of the projects seemed more manageable. It was a joy to work with these students during the term of the project. We had a meaningful number of review iterations, unlike a typical GSoC project where a student and her mentors sit in a dark cave for a long time, send out the first draft too late, and the participant do not get enough time to do meaningful iterations of reviews (it was also a huge plus from our project's point of view that there were even responsible post-program follow up to complete the unfinished bits). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Jeff King p...@peff.net writes:
This is not related to GSoC anymore, but I think handling multiple
versions is already pretty easy. You can just install to
$HOME/local/git/$TAGNAME or similar, and then symlink the bin/git
binary from there into your PATH as git.$TAGNAME (e.g., git.v1.7.8). Git
already takes care of the messy bits, like making sure sub-programs are
invoked from the same git version.
I already do this automagically with this script:
https://github.com/peff/git/blob/meta/install/prefix
I just set prefix in the Makefile based on the script, and when I
make install tags or topic branches, they go to the right place (and
the links script in the same directory maintains the symlinks for me).
I never bothered to even submit those scripts to contrib, because I
figured they were so specific to my setup, and to keeping dozens of git
versions around (when debugging, it's nice to be able to check an old
version's behavior without even having to build it).
Yeah, I have been using the Make (in the todo branch, to be checked
out in Meta/ subdirectory of the working tree) script for exactly
this. After tagging a release, I'd do
git checkout -B snap v1.8.1.3
Meta/Make install install-doc
to install them in $inst_prefix/git-snap-v1.8.1.3. A rungit
script can then be used like:
rungit v1.7.0 checkout blah
-- rungit script -- 8 -- rungit script --
#!/bin/sh
# Run various vintage of git
variant=${0##*/}
: ${RUNGIT_BASE=$HOME/g/$(getarch)}
case $variant in
rungit)
case $# in
0)
echo 2 which version?
exit 1
;;
esac
variant=$1
shift
;;
esac
case $variant in
-l)
for d in $RUNGIT_BASE/git-*/bin/git
do
d=$(basename ${d%/bin/git})
d=${d#git-}
d=${d#snap-}
echo $d
done
exit
;;
git-*)
variant=${variant#git-} ;;
v[0-9]*)
variant=snap-$variant ;;
esac
d=$RUNGIT_BASE/git-$variant
if test -f $d/bin/git
then
exec $d/bin/git $@
else
echo 2 $variant: No such variant for $a
exit 1
fi
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Jeff King wrote: On Mon, Feb 18, 2013 at 11:34:24AM -0800, Jonathan Nieder wrote: Some potential projects (unfiltered --- please take them with a grain of salt): [...] - collaborative notes editing: fix the default notes refspec, make sure the notes pull workflow works well and is documented well, offer an easy way to hide private notes after the fact without disrupting public history I know you said a grain of salt, so please don't feel like I'm beating up on your idea. I'm picking this one because I think it has some characteristics of projects that have not gone well in the past, so it's a good illustrative example. IMHO, this is the type of project that is likely to fail, because most of the work is not technical at all, but political. Changing the default refspecs is a few lines of code. But the hard part is figuring out where they should go, the implications of doing so, and how people are going to react. I think I agree, if by likely to fail you mean easy to underestimate the difficulty of. I actually think it would be a pretty good summer student project, for a few related reasons: * Years of evidence show it is a hard problem. It would be a good notch in the belt of whoever takes the project on. * It does not require a deep understanding of git internals. A good familiarity with the git user interface, on the other hand, would be essential, but I hope that is becoming more common among students these days. * It requires good taste and design sense, which are something it would be nice to cultivate and encourage. * The change is necessary and the satisfaction of helping a student through the process might be enough to finally get it done. * If an amazing candidate finishes the make collaboration possible task early, there's plenty of valuable, interesting, and technically complicated follow-on work regarding the related share some notes while hiding others to fill the rest of the summer. The code change for the most basic subset of make collaboration possible would presumably be a changed refspec, some documentation, and some tests. On top of that there is presumably some automagic incorporation of upstream notes to be cooked into git pull. Some better conflict-resolution magic. Example scripts to generate notes. Support for the format-patch / am workflow. gitweb support for showing notes. It's a good example of when it's useful to not be afraid of failing to please everybody and just get something done. I also can't think of any examples of such technically straightforward student projects being tried before. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
On Tue, Feb 19, 2013 at 12:23 AM, Thomas Rast tr...@inf.ethz.ch wrote: * Naturally that ideas page is a bit stale now, and three projects shorter. Please propose new ideas and refresh or delete the old ones! In particular some projects spawned long discussions on the list, and the results of those discussions should be integrated to avoid deja vus. A proposal from what I've been involved lately: inotify support to eliminate lstat and readdir syscalls. The scope may be small. But we could aim to get it merged in master or at least next by the end of GSoC. Or extend to another platform besides Linux, it helps ensure we have good abstraction. My free time goes up and down unexpectedly, not sure if I can commit to be a mentor. But I'm definitely interested and will support whenever I can. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Potential GSoC13 projects (Re: Google Summer of Code 2013 (GSoC13))
On Tue, Feb 19, 2013 at 4:11 AM, Jonathan Nieder jrnie...@gmail.com wrote: Ramkumar Ramachandra wrote: Jonathan Nieder wrote: - cross-compilable git Why, exactly? Git for embedded devices? My personal motivation would be building Git for Windows while spending as little time on Windows as possible. People deploying git to 32-bit x86, 64-bit x86, and ARM (think ARM laptops) might also find it handy. I did something like that long ago (for cross compiling Windows). Although I eventually gave up on the Windows front as I was too lazy to test on Windows :) (and Wine by that time was not good enough) I think some of my patches are in the archive. Will dig them up. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra wrote: The short undiplomatic version of that is that our mentors suck (I'm not pointing fingers, but that's what I infer from failing projects). Hold on a second. I'm not remembering such a grim outcome with 100% failure from prior summers of code as you're describing. Before I start beating myself up, I guess I'd like a little more information --- is there some specific project or statistic that you're thinking of that brings you to that conclusion? [...] I propose that we have one thread for every proposal where we can all discuss the implementation outline- this will serve as authoritative source of information for students, and for picking mentors (the people who contribute most to the discussion). Students should be matched with mentors on an individual basis. How is that different from what happened in previous summers where students made proposals, received feedback, and were accepted and matched to mentors or rejected based on how the discussion went? Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: ... I think the real issue is everybody in the GSoC mentor candidate pool grossly underestimates the scope of suggested projects, does not encourage students to send early drafts to the public from the beginning, and perhaps overestimates the ability of total beginners. After seeing my index-thing is too big in scope warning repeatedly ignored for the last year's GSoC, I am not very hopeful unless the attitude towards GSoC and its students drastically changes on our mentors' end. The short undiplomatic version of that is that our mentors suck (I'm not pointing fingers, but that's what I infer from failing projects). I was conflating between people who add suggested project and who act as mentors. I do not think mentors are primarily responsible for bad suggested projects. Our mentors may be wonderful but I do not have enough evidence to judge either way. They are mostly student-facing and I as a bystander to GSoC process didn't see much of their involvement in their students' work---maybe that is how it is supposed to work, maybe not. The only failing of them observable from my point of view was that we repeatedly saw the initial round of patches come very late. But my complaints were primarily about those sure-to-fail project suggestions. I propose that we have one thread for every proposal where we can all discuss the implementation outline- this will serve as authoritative source of information for students, and for picking mentors (the people who contribute most to the discussion). Students should be matched with mentors on an individual basis. You are being unreasonable and/or unrealistic. A topic that needs a large discussion thread to pre-discuss design and outline by many existing members of community and mentor candidates is a sure sign that the topic is too big for a beginner. A topic that needs only a small enough discussion thread on the other hand will come to a polished conclusion before even the student shows up. This is exactly why I suggested doable as a private, at most two-weekend hack by an experienced as a quick and dirty way to measure the size of a project. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Google Summer of Code 2013 (GSoC13)
Thomas Rast wrote: Ramkumar Ramachandra artag...@gmail.com writes: [...] On a related note, I don't like our Wiki. It's down half the time, and it's very badly maintained. I want to write content for our Wiki from the comfort of my editor, with version control aiding me. And I can't stand archaic WikiText. Agreed on all of those points. Putting the Wiki on GitHub fixes that. But it means contributors need to have a GitHub account. On the other hand, I think kernel.org wiki contributors need an account these days? And GitHub is putting some active effort into finding and killing spammy accounts, which might keep wiki spam down (I do not pay too much attention to those efforts, but on kernel.org, it is mostly up to the Git community to do it ourselves). No, I'm against using the GitHub Wiki for neutrality reasons. There is one easy way to fight spam: don't expose a web-based editing interface at all. It's mainly going to be maintained by the community, and we're all much more comfortable in our editors and git. We can give the regulars direct commit access and ask the rest to submit pull requests. Make it cost pennies, so any of us can easily afford it: just a cheap domain, DNS, and static HTML hosting. I suppose since github's wiki system (gollum) is open source [1] it wouldn't be too hard to set up another instance somewhere. Bonus points for importing all the old data in mediawiki format first, which is also apparently supported. Yes, I am aware. However, I don't think gollum fits our purposes well: we really don't need much more than plain text. What do you want to import? We can copy out the text from the previous GSoC pages, but most of the other pages are filled with ancient junk. We don't want a museum: we want a clean Wiki with crisp, clean up-to-date information. But that just shifts the point of failure from the entire github team to one or two people who end up administering the server. ... which is the entire problem. We don't want to administer things. We're programmers who're competent at writing plain text and maintaining git repositories, so let's stick to doing that; I'm pushing for static HTML hosting for exactly this reason: there is nothing to administer, no security exploits, no unexpected breakages. It also reflects our community's affinity for simplicity. Perhaps a better solution would be to ask Scott or Peff to create a gollum instance under git-scm.com, which they're already hosting? Failing that, just a CNAME entry for wiki under git-scm.com would suffice. What does static HTML hosting cost anyway? (It seems people got over *that* neutrality issue quickly enough.) There's a big difference between having git-scm.com as our official website, and hosting our official Wiki on https://github.com/git/git/wiki. Although it is built by people working in GitHub, with its sources in github.com/github/gitscm-next, it makes no effort to reference GitHub directly. Ofcourse, there are many things I dislike about the website, and would have preferred a community-built one. Unfortunately, building a website involves doing design work that we programmers are incompetent at. So, I think of it as a practical compromise that we have to live with. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
