Thanks for getting the ball rolling.
One thing unrelated to the proposal I have been wondering about was how well our release cycles mesh with the GSoC timeline.
Comparing the GSoC timeline and the Git Calendar:
http://www.google-melange.com/gsoc/events/google/gsoc2012
http://tinyurl.com/gitcalSome basics to consider:
- Typically one cycle of our development lasts for 8 to 10 weeks, and at
around its 5th or 6th week, the major changes for the next release are
expected to be more or less ready.
- As we have about 20 weeks between the beginning of post-1.7.10 cycle
and pencils-down time for GSoC, and also people tend to slow down or
stop late June to early July for summer holidays, I am planning to make
these cycles last a bit longer for 10 weeks.
The way I envision the experience for this year's students would go are like this:
* GSoC student proposal acceptance (April 23rd)
The students are expected to start "bonding" with the community.
This is at the beginning of week #4 of the post-1.7.10 cycle. Students
have a chance to observe and learn how a change is proposed, its design
debated and patchset polished from beginning to end, even if they wait
before joining the mailing list until this date.
* GSoC student first day of business (May 21st)
The students are expected to start coding.
This is at the beginning of week #8 of the post-1.7.10 cycle,
1.7.11-rc0 should have been tagged several days before, and 1.7.11-rc1
is scheduled to be tagged in a few days. Once we hit this point, we
usually do not queue anything large even to 'pu' until the final
release to encourage people to concentrate on the upcoming release,
which may be OK for the first couple of weeks for GSoC students (they
won't have anything to show that early).
The final batches of large changes that were previously discussed and
polished would still be graduating to 'master', whose earlier parts of
lifecycle the students may not have seen, but smaller and more obvious
changes proposed after they joined the community would go their full
lifecycle from 'pu' thru 'next' down to 'master', and the students can
learn from these topics how the development process works.
* Beginning of post 1.7.11 cycle (June 11th)
The students would be working furiously for midterm.
At this point, the students have worked for 3 weeks with their mentors.
Good students may at least have design sketches ready to be presented
at this point, if not a working code.
* GSoC midterm evaluation (July 9th)
This is at the beginning of week #5 of the post-1.7.11 cycle. The
student's changes should at be ready for 'pu' by this time, or there is
no chance of them being in the upcoming release.
The students would have had 7 weeks to work up to this point, and they
have 4 more weeks to polish their work to 'next' and to 'master' until
1.7.12-rc1, and another 2 weeks to further fix late bugs in 'master'.
* GSoC pencils down (Aug 20th)
This is at the end of week #10 of the post-1.7.11 cycle, and 1.7.12
should be already out the day before.
Our release cycle was never scheduled around GSoC timeline for the past GSoC students, so I do not know what effect, if any, our pre-release freeze period had on our past students' work (I would appreciate hearing from past student about their experiences).
In any case, it seems that they coincide fairly well for this year's students.
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.
Jeff King
