On Monday 22 March 2010 01:33:47 Daniel Barkalow wrote: > One thing to keep in mind is that you'll get review at a slower rate than > you'll make progress, and you'll need progress, review, and fixes to get > integration. This means that the optimal pattern is to post incomplete > things (marked [RFC PATCH]) when you've got enough there to show where > you're going and you think the quality of the code you have is pretty > good. Your patches go out, and you work on the next step while other > people find them, read them, write comments, and you get the comments. > Then you incorporate the changes for the comments into the next round (or > you acknowledge the need for changes, but defer them to the third round, > if you've got a second round ready). I agree but I think that it should be stressed that a GSoC project should be split into many milestones and that each milestone should be in itself a worthwhile improvement to the previous state. So that when a milestone is reached, the code can be sent to the list for review (marked [RFC PATCH]) and then improved and sent again as many times as needed (marked with v1, v2, ...) to get it merged. And it is important to understand that responding to reviews and doing whatever is needed to get the code for the first milestones merged _is more important_ than developing code for the next milestones. Because it's much better for everyone at the end of the GSoC if only half of the project is finished but merged, rather than if all the project is "finished" but nothing can be merged. The code that can't be merged will rust very fast and will probably need quite some work that unfortunately few people may want or be able to do fast enough after the end of the GSoC. And that means that basically the work that has been done will be mostly lost which is very _very_ frustrating for students, mentors, reviewers and everyone involved... Best regards, Christian. -- 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