> We should also acknowledge the pain in the other direction - there is a >> category of "small fixes" where our response (although understandable give >> our limited resources) is viewed as out of line with respect to other open >> source projects. >> > > Can you provide some examples? I don't work very well with general > statements. >
Should of been more clear that I agree with everything you say, and was trying to add the idea of how we look to potential contributors into the mix. Each case I can think of (jdbc timezone fix that I rejected, wps pull request that went from simple to insurmountable) has a danger of distracting from the point - that developers expect to be able to contribute a fix and walk away. Both of those examples had very clear reasons why they were rejected - but the impression remains that our codebase is hard to work with. A review guide as you describe it, can help both those new to the geoserver community conduct a review and feel confident in the result, and those contributing to the project to know what to expect and that we are treating them fairly/consistently. It seems by your comment one way to handle this would be to increase the > resources, so that the reviewer of the day is not so hard pressed to do > things quickly and get back to work/family. > Yeah, the real strain here is lack of resources on the project. > If it's relaxing the amount of stuff to be changed in order > to require a contribution agreement, I don't see a problem, the current > practice has been set basically following Locationtech advice, I don't > think anyone around here wanted to make it so strict. > That was more apache advice when we were setting up OSGeo, but I do understand your point. If it's not requiring tests, then you have my unconditional -1, too many > people making too many chances unaware of each other, if there are no tests > you might as well not contribute, the change is going to be broken soon > anyways. Again, you're talking too much in generic terms for me, could you > propose something more specific? > A test case and documentation are often considered unreasonable. We do a good job of communicating why they are required. And I agree with our limited resources submitting a fix without a test case is wasted effort. So for something more specific - at the end of a "review checklist" we could include a paragraph inviting the reader to join geoserver-devel and ask questions. Or at least acknowledge that this is hard work and the checklist helps us share the work more evenly.
------------------------------------------------------------------------------
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
