Hi everyone.

Starting to look at some of the GSoC applications already, I can see
that some students are already starting to fall into the trap of "code
during the summer and get it merged at the end".  As we've seen in the
past, this is a poor model, as it tends to lead to very large and
difficult to review branches, which then tend to take a long time to
finally get merged.

I hardly need to explain why this is bad.  The longer a branch remains
unmerged, the harder it is to merge, as merge conflicts will tend to
grow on it.  The review process, indeed, the community in general,
slows down after GSoC in the "off season", so this is actually a very
poor time to try to get a large branch merged.  If anyone else's work
depends on the unmerged work, it cannot be merged until that work is.
For example, we could only recently merge Matthew's GSoC work because
it relied on Tom's GSoC work, which I only finished reviewing in
January.

So I think this year we should make an extra effort to get GSoC work
submitted throughout the summer.  Whenever an atomic amount of work is
submitted, it should be submitted as a pull request.  An atomic amount
of work is anything that is functional, and doesn't break anything.
Based on what I've seen so far in the timelines in proposals for this
year, this should happen roughly once a week.

As many of you know, I myself have a GSoC branch from 2010 that has
not yet been merged. Taking this branch as a pattern, along with
several others, I think that one key reason why this happens is that
the student waits until he has enough done so that it is functional on
the user side.  I think we should reconsider this plan.  If the
student is implementing a large algorithm, it is often quite some time
before it gets to this point.  So I think rather we should merge work
even if it's only internal code that doesn't do anything yet.

I think this will also encourage positive behavior, such as writing
documentation and tests for code as it is written, rather than later
on, and writing tests for internal functions as well as external ones.

By the way, I don't want to put any blame on any GSoC students for
this, or anyone else for that matter.  Past occurrences of this are
past, so we should just learn from them.  If you're applying this
year, just make sure you structure your timeline to include submitting
code often, rather than at the end of the program.  We need to work
together as a community, both mentors and students, to try to get code
merged sooner.

I'd love to hear any thoughts on how we can better achieve this, as
well as any other anti-patterns you've noticed that lead to these
large branches.

Aaron Meurer

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Reply via email to