Re: GSOC idea: build in scripts and cleanups

[Jeff King <peff@peff.net>]

On Mon, Apr 04, 2011 at 11:09:00AM -0700, Junio C Hamano wrote:

> 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 agree. I think it's important to take review-reroll cycles into
account. Not just in terms of allocating time, but also considering the
latency, and keeping the student's pipeline full of work while waiting
on review.

To that end, I think it's useful to break the problem up as much as
possible, and feed chunks to the list as quickly as possible. Even if
you end up with something like:

  Week 2: send refactoring of functionality X
  Week 3: build new functionality Y on top of X

Obviously "Y" is going to depend somewhat on the refactoring of "X". But
you can say in the RFC/PATCH for Y that X is still ongoing, and to
review with that in mind. And that keeps the student doing something
during week 3 while reviews for X flow in.

In the past, students haven't been very engaged with the list community,
and I think that has hurt us. The code gets dumped as a whole at the
end, and review is a lot harder, and GSoC is over, so the student ends
up busy with going back to school. And the student never really learns
the "normal" way that contributors interact with the community, which
makes them less likely to become long-time contributors.

So I'd really like to see this year's projects breaking contributions
into smaller, reviewable bits and submitting over the course of the
whole summer.

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

Yeah, I think that is reasonable. Stuff that makes it into "next" is
usually of good quality, but just needs time to shake out bugs. Every
once in a while we find that something in next turns out be utter crap,
but usually it is obvious before it even gets merged there. Hopefully a
student will be available to fix minor bugs as the topic cooks in next,
but if not, it is probably something the mentor can do.

-Peff