Tue Jun 1 14:24:22 CDT 2010
On Tue, Jun 1, 2010 at 2:57 PM, Matthew Brett <email@example.com> wrote:
>>> Well - but that is because you don't maintenance. Imagine a
>>> maintainer puts in a lot of effort to make the code well-documented
>>> and tested. Then, you have put in new code that has neither
>>> documentation nor tests. As a good maintainer, it's really painful
>>> for them that there's new code without documentation or tests. They
>>> can only feel abused in that situation, because it seems as if you are
>>> expecting them to clean up after you - without asking.
>> I don't think that is fair. I have been "maintaining" SciPy and NumPy code for over 10 years. I have done an immense amount of work in porting SciPy to NumPy and continuing to fix bugs that I am made aware of. I don't have as much time to commit to SciPy as I would like.
> I wasn't really saying whether it was fair or not, I was only trying
> to explain why it might cause offense.
> When I say that you don't do maintenance, I mean that you are not
> currently the person who has to make sure that the code is readable
> and maintainable. That is hard and often thankless work.
> I presume that you agree that numpy and scipy code should have
> documentation and tests. I presume also that when you commit code
> without documentation or tests, that you do not usually intend to come
> back and do these later - say - before the next release. That means
> that someone else has to do it. It will take them a lot longer than
> it would take you because they don't know the code as well.
> I realize this is not your intent, but, it's tempting in this
> situation to feel that you think that your time is more valuable than
> the person who has to write the documentation and tests - and that's a
> painful feeling to have - hence - I believe - the level of bad feeling
> that arises...
Just to emphasis my point
I'm mainly concerned about quality control of trunk.
Open source development is still a collaborative process, and the
person to write the code and the final tests doesn't necessarily have
to be the same person. For example, Skipper is doing a lot more than
his "fair" share of writing formal tests in statsmodels, and I'm
writing a good amount of test code for scipy.
(Skipper and I usually provide sufficient documentation, developer
comments, and references that we are in most cases able to understand
But if the original coder doesn't have the time to bring the code up
to testing and documentation standard, then the code should stay out
of trunk until someone finds the time to get it through a review and
quality control process. The problem is that, that someone might not
be able to figure out how to fix possible problems (my example is
Fisher's exact test).
> See you,
> SciPy-Dev mailing list
More information about the SciPy-Dev