On Fri, Mar 02, 2012 at 01:48:31PM -0800, Junio C Hamano wrote: > One thing unrelated to the proposal I have been wondering about was how > well our release cycles mesh with the GSoC timeline. > [...] > In any case, it seems that they coincide fairly well for this year's > students. Thanks for a thorough analysis. This isn't something we really thought too much about in years past (and it seems like you have been paying more attention to the scheduling in general this past year, or at least communicating more openly about). So given that the schedule coincides reasonably well, I think it make sense to consider this a "pilot" year, and to make a mental note to talk post-GSoC about how the schedule worked (or didn't work). Part of me thinks that no matter how much schedule planning we do, students will always go their own and deliver work in fits and starts. It's their nature (and I say that as somebody who managed to be a student for 24 consecutive years :) ). > By the way, I also considered splitting the 20-week period into two and a > half cycles, coinciding -rc1 of the third cycle after the upcoming 1.7.10 > release and GSoC pencils down date. It would make the student success > criteria "Is it in 'master'?" instead of "Is it in a release?", but the > overall schedule did not work as well as the above. Actually, we have been pretty lenient with student success in the past. Many projects have been marked successful even if their code as not yet in master, and in many cases never made it. I think part of that is because we are often over-ambitious with our projects, and the mentors and students realize near the end that the project is much large or more difficult than originally realized. To some degree that is a good thing, as it means students are working on cool, interesting things that haven't been done before. But it may also be worth making an effort to split ambitious projects into bite-sized chunks. Even if step 3 doesn't make it in, steps 1 and 2 might end up as a good project in themselves, and that is much better than the student contributing nothing. In some cases, too, the student pushes forward thinking on a subject among the project members. The rev-cache code did not end up getting merged. But I'm not sure I would consider it a failure. It was an interesting experiment, and I think ultimately the complexity tradeoff was a bit distasteful. However, the negative result and the experience gained by the community were still worthwhile. -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