Aaron, +1
I fully agree with this. It takes discipline to break up a big project into a set of smaller pull requests, but it is extremely important. Students need to think very carefully about how they will do this and describe their plan in their GSoC application. Obviously, mentors will also have to be disciplined in doing code reviews and helping the code to get in. Cheers, Brian On Fri, Mar 30, 2012 at 11:27 AM, Aaron Meurer <[email protected]> wrote: > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- Brian E. Granger Cal Poly State University, San Luis Obispo [email protected] and [email protected] -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
