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 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". What do regular reviewers and potential mentors think? Perhaps we have more stringent quality requirements than other open source projects that take "commit first, review and fix as necessary" cycle, and they may declare success when "commit first" happens. If that is the case, 'next', whose definition is "without glaring design and implementation bugs and fit enough for dogfooding, but needs extra polish", might be a better success criteria to be fair for our students. I am not in the mentor pool and I would rather not to be to stay neutral, so I'll leave it up to the mentors. -- 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