On Jul 5, 2011, at 1:36 AM, Johan Rydberg wrote:
On 7/1/11 6:08 PM, Itamar Turner-Trauring wrote:
In order to have at least some anecdotal evidence -- I've had some patched rejected, probably on sound basis. But the experience always leave you with a feeling that you got stabbed.
We're always very grateful for contributions. I'm very sad to hear that you feel like you "got stabbed".
Sometimes it _is_ be better to get some basic functionality in place, instead of arguing about how things should be done "the right way".
Can you point to a specific ticket where you think this was the case? I have this same general feeling, but pretty much all of the reviews I found when I went looking for specific examples included at least some significant coding-standard, documentation, and test coverage problems. If we can find more specific examples, perhaps we can prevent this from recurring. I do agree that we don't want to block every ticket on the absolute best possible implementation; but, allowing changes that don't have test and documentation coverage is a recipe for creating an unmaintainable mess. Trust me, having dealt with Twisted in both modes, it's harder to get a patch into a release if the requirement is "demonstrate to everyone that it doesn't break everything without tests and documentation". It's just that it moves the work from you, the contributor, to a special hell that the release manager inhabits for months of painful pre-release debugging, or users who notice that all their applications are broken and file lots of bugs.
From time to time you find a ticket that you want fixed, and start working on it, but end up never submitting it since you already know that even if it fixes the problem it will be shot down, since it doesn't do it this or that way.
In these cases it would be best to file the ticket and describe your potential solution before implementing it. You can even put the 'review' keyword on it to indicate that you want feedback from a contributor before proceeding. -glyph