I personally think that lines of code should not be used as a metric for almost anything, and certainly not anything relating to the complexity of the code. The reason is that some lines of code are much more complex than others, and the difference is great. Even if we make the obvious split between documentation (docstrings, comments, whitespace) and real code, there is still a big difference, and it will vary from person to person. A class with a bunch of simple properties may take up many lines (say 100), but will be very simple. A complex function, may be only 20 lines. Furthermore, improved documentation may have the result of making the code easier to read, even though it makes things longer.
Counting commits is not really very good either, because different people will put a different amount of work in each commit. This will also vary based on how complex the coding work is. This is especially true for new GSoC students, as most of them will have poor committing habits, at least at the start. I don't think it's unreasonable to just say "atomic" change. If you wrote a function or class, and enough of it is implemented so that your test suite for it passes, then it can be submitted. If you make more changes before anyone has started the review, you can push it to the same branch. I remember when I first did GSoC that I had work that was submittable by this standard after the first week (this was long before pull requests). Ultimately, I think the mentor and student will find a good balance throughout the summer, which will vary based on the individuals and the specific projects. The size of a good pull request can vary by a lot, I think. So long as we avoid big pull requests, we will be doing much better. By the way, another thing that we should encourage is to submit orthogonal changes as separate pull requests. If the GSoC student has to fix some bug in some other module from the one he is mainly working on for his project, that fix should go in a separate branch. This can then be reviewed quickly and merged into master, and then he can just base his main work off of master. Aaron Meurer On Sun, Apr 1, 2012 at 6:08 AM, Joachim Durchholz <[email protected]> wrote: > Am 31.03.2012 11:59, schrieb Tom Bachmann: > >> I think it may be helpful to give an explicit ballpark estimate of >> maximal desired pull request size, e.g. 10 commits. > > > If a ballpark figure it is, give one in terms of lines of added code. Or in > terms of days of raw coding (and warn that 1 day of coding may mean 3-5 days > total since it includes thinking, discussing, and correcting). > Some of my commits were several hundred lines. A pull request with ten > commits of that size, and it's very probably entire unmergeable, and most > certainly not reviewable. > > > -- > 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. > -- 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.
