On Sun, 21 Mar 2010, Ramkumar Ramachandra wrote: > Hi, > > > Personally, I would have little problems just adding the remote and > > checking out the branch, just to test the thing after I got a promising > > progress report. And I think those who are truly interested in > > git-remote-svn will have little problems, either. The important part would > > be the visible progress (i.e. mails by the student to this list). > > Thanks for the elaborate explanation. The way I see it, there are two > extreme situations I must avoid. The first is being opaque for the > risk of not being able to integrate it into git.git at the end of the > summer term. The other extreme is worrying so much about the > integration of each little bit that the project keeps getting > detracted, and eventually loses focus. To strike a balance, I will > post progress reports to the mailing list (atleast) once a week, and > keep a public development branch for myself. Occasionally, it might > help to post patches for small components of the project with > unittests to get a wider test audience. 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). The thing that really stalls a project, either in the middle or at the end, is when you can't do anything while you wait for a round-trip exchange with reviewers (or multiple round-trips, if the comments are non-trivial and you need further explanation or to propose alternatives). The longer you anticipate between sending the patches out and having them included, and the busier you can stay in that time, the better. Overlapping does mean that you end up reworking later patches, but (unless you can save up hours of work) it's better to have patches to rework than to be starting from scratch at that point, and it's better to know what you'll have to rework as early as is feasible. -Daniel *This .sig left intentionally blank* -- 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