On Mon, Apr 04, 2011 at 11:09:00AM -0700, Junio C Hamano wrote: > Robert David <robert.david.public@xxxxxxxxx> writes: > > > 1) Pre-coding time > > 2) 1-3 week > > 3) 4-5 week > > 4) 6-7 week > > 5) 8-11 week > > Extend the C code to the state it should be. > > Adopt other git commands to work with the new interface correctly. > > Test extensively. > > Update documentation where needed. > > > > 6) 12 week > > Write more documentation, to document what was done and how. > > Correct bugs and test. > > I am afraid to say that the above schedule is too ambitious and does not > leave any time for reviews and re-rolls. Please keep in mind that > historically patch series by more experienced contributors of substantial > size (comparable or even smaller scale than the topic you are proposing) > all typically took three or four review-reroll cycles, if not less, and we > don't automatically get extra review bandwidth just because GSoC is going > on. I agree. I think it's important to take review-reroll cycles into account. Not just in terms of allocating time, but also considering the latency, and keeping the student's pipeline full of work while waiting on review. To that end, I think it's useful to break the problem up as much as possible, and feed chunks to the list as quickly as possible. Even if you end up with something like: Week 2: send refactoring of functionality X Week 3: build new functionality Y on top of X Obviously "Y" is going to depend somewhat on the refactoring of "X". But you can say in the RFC/PATCH for Y that X is still ongoing, and to review with that in mind. And that keeps the student doing something during week 3 while reviews for X flow in. In the past, students haven't been very engaged with the list community, and I think that has hurt us. The code gets dumped as a whole at the end, and review is a lot harder, and GSoC is over, so the student ends up busy with going back to school. And the student never really learns the "normal" way that contributors interact with the community, which makes them less likely to become long-time contributors. So I'd really like to see this year's projects breaking contributions into smaller, reviewable bits and submitting over the course of the whole summer. > I am starting to suspect that it might make sense to say "as far as GSoC > participation is concerned, we would call a topic "merged upstream" when > it hits 'next', even if it is not ready for 'master' at the end of the > term". Yeah, I think that is reasonable. Stuff that makes it into "next" is usually of good quality, but just needs time to shake out bugs. Every once in a while we find that something in next turns out be utter crap, but usually it is obvious before it even gets merged there. Hopefully a student will be available to fix minor bugs as the topic cooks in next, but if not, it is probably something the mentor can do. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html