Marcus Denker marcus@ira.uka.de wrote:
bugs are good, because bugs generate tests.
I'm sorry, but this seems to be a little disconnected from reality right now. I agree they should, but they don't. And expecting everyone to start churning out lots of SUnit tests seems a bit optimistic. Though any ideas on how to achieve this would be very welcome - I do agree that the easiest fixes to approve are the ones that turn a test green, so that would be a very sound technical basis to use, if we find the way to cultivate it.
- It could be not-that-perfectly documented. To me, the alternative seems to be: Not adding, or adding a slightly-not-perfect thing. What is worse? I would *really* prefer to e.g. have some feature now instead of waiting indefinitly. But that may only be me.
Make it green. Then refactor.
Again, this seems reasonable if you can make some assumptions, such as that people will actually refactor. But this seems again, optimistic. If people aren't joyfully reviewing one anothers patches, why do you assume they'll cheerfully refactor one anothers "ugly code that got in the image"?
We should also consider the case: 3) The patch could be completely inappropriate, like (apparently) Martin Wirblats patch related to Pool declarations. Some patches, if accepted, simply reduce a solutions coherency, and make it harder to understand and improve in the future.
Daniel
Daniel if we open more the process, I think that harvester/guides/ should have a veto vote.
Stef
On Vendredi, oct 17, 2003, at 10:39 Europe/Zurich, Daniel Vainsencher wrote:
Marcus Denker marcus@ira.uka.de wrote:
bugs are good, because bugs generate tests.
I'm sorry, but this seems to be a little disconnected from reality right now. I agree they should, but they don't. And expecting everyone to start churning out lots of SUnit tests seems a bit optimistic. Though any ideas on how to achieve this would be very welcome - I do agree that the easiest fixes to approve are the ones that turn a test green, so that would be a very sound technical basis to use, if we find the way to cultivate it.
- It could be not-that-perfectly documented. To me, the alternative seems to be: Not adding, or adding a slightly-not-perfect thing. What is worse? I would *really* prefer to e.g. have some feature now instead of waiting indefinitly. But that may only be me.
Make it green. Then refactor.
Again, this seems reasonable if you can make some assumptions, such as that people will actually refactor. But this seems again, optimistic. If people aren't joyfully reviewing one anothers patches, why do you assume they'll cheerfully refactor one anothers "ugly code that got in the image"?
We should also consider the case: 3) The patch could be completely inappropriate, like (apparently) Martin Wirblats patch related to Pool declarations. Some patches, if accepted, simply reduce a solutions coherency, and make it harder to understand and improve in the future.
Daniel _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
squeakfoundation@lists.squeakfoundation.org