Re: Google Summer of Code 2013 (GSoC13)

From: Thomas Rast <trast@inf.ethz.ch>
Date: Feb 19, 2013, 16:39 UTC
Message-ID: <871uccs1f3.fsf@pctrast.inf.ethz.ch>
In-Reply-To: <7vtxp86zcs.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 11 quoted lines

> Thomas Rast <trast@inf.ethz.ch> writes:
>
>> In defense of Thomas, whose project was mentioned earlier as a prime
>> example of something that is "too big":
>>
>> He's in fact still working on the index-API angle, as part of a thesis
>> at university.
>
> That is probably a good indicator that it was too big for a summer
> student.  It also is good to hear that the topic is being looked at
> ;-).

Not really: the API angle was never part of the proposal. The timeline was [1 if you have access]:

  24/04 - 01/05: Document the new index format.
  02/05 - 11/05: Create a converter of the old index format to the new format.
  12/05 - 18/06: Parse the index from disk to the current in-memory format. The
  old index format shall still be readable.
  19/06 - 09/07: Implement the re-reading of a single record, if the crc32 doesn't
  match (Meaning the record has been changed under the reader).
  10/07 - 21/07:  Map the current internal structure to the new index format.
  22/07 - 31/07: Change the current in-memory structure to keep track of the
  changed files.
  01/08 - 13/08: Write the index to disk in both the old and the new format
  depending on the choice of the user and make sure only the changed parts are
  really written to disk in the new format.
  11/08 - 13/08: Test the new index and profile the gains compared to the old
  format.
  /* Development work will be a bit slower from 18/06 to 21/07 because at my
   * University there are exams in this period. I probably will only be able to
   * work half the hours. I'll be back up to full speed after that. */

I think this case is somewhat symptomatic for one possible cause of dragged-out non-inclusions _after_ GSoC: there's a certain scope creep caused by striving for the perfect, long-term maintainable code.

The solution IMHO is to _both_ recognize such possibilities for scope creep, and cut down the proposals to a size where a student has a reasonable chance of achieving the code quality required for inclusion.

(The latter option has been mentioned a few times, but I wanted to make people aware that the scope creep is happening, too.)

Footnotes: 
[1]  http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/tgummerer/1

-- 
Thomas Rast
trast@{inf,student}.ethz.ch