Re: GSoC 2012 application process

Jeff King [off-list ref] writes:

... a wiki page for
project ideas:

  https://github.com/peff/git/wiki/SoC-2012-Application
  https://github.com/peff/git/wiki/SoC-2012-Ideas

The application is due March 9th (next Friday).

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/gitcal

Some 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.

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