Re: GSOC idea: build in scripts and cleanups

[Junio C Hamano <gitster@pobox.com>]

Robert David <robert.david.public@gmail.com> writes:

> 1) Pre-coding time
> 2) 1-3 week
> 3) 4-5 week
> 4) 6-7 week
> 5) 8-11 week
> Extend the C code to the state it should be.
> Adopt other git commands to work with the new interface correctly.
> Test extensively.
> Update documentation where needed.
>
> 6) 12 week
> Write more documentation, to document what was done and how.
> Correct bugs and test.

I am afraid to say that the above schedule is too ambitious and does not
leave any time for reviews and re-rolls.  Please keep in mind that
historically patch series by more experienced contributors of substantial
size (comparable or even smaller scale than the topic you are proposing)
all typically took three or four review-reroll cycles, if not less, and we
don't automatically get extra review bandwidth just because GSoC is going
on.

I am starting to suspect that it might make sense to say "as far as GSoC
participation is concerned, we would call a topic "merged upstream" when
it hits 'next', even if it is not ready for 'master' at the end of the
term".

What do regular reviewers and potential mentors think?  Perhaps we have
more stringent quality requirements than other open source projects that
take "commit first, review and fix as necessary" cycle, and they may
declare success when "commit first" happens.  If that is the case, 'next',
whose definition is "without glaring design and implementation bugs and
fit enough for dogfooding, but needs extra polish", might be a better
success criteria to be fair for our students.

I am not in the mentor pool and I would rather not to be to stay neutral,
so I'll leave it up to the mentors.