You'll have to explain what "atomic" is. This can range from five-liners to
five-thousand-liners.
That's my point exactly.
My point here is that a five-LoC commit, even if it's atomic, isn't
worth it.
And a 5000-LoC commit, no matter how well it fits the "atomic"
definition, is not reviewable and should be redesigned so that smaller
atomic commits can be made.
A figure of a few hundred lines is not technically correct, but it will
nudge people in the right direction. (Which is good enough in this context.)
On a related point: To use atomicity as a criterion, we need a definition.
My definition would be: "Cannot be broken into pieces without losing
property XYZ." However, I'm coming up blank with what XYZ is, and
without that, the criterion cannot be applied. In fact I think the
definition of XYZ is the salient point here.
In general, I think both the definition of atomicity and ballpark
figures would be useful to newcomers (experienced developers already
know what a good pull request is). So something like this might work:
"Pull requests need to be 'atomic', i.e. [definition of 'atomic' goes
here]. If unsure, aim for a pull request size of around 300-500 lines of
new code."
--
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.
