On May 15, 2012, at 9:38 PM, Alex Huang wrote: >> Contributors - people who contribute in one way or another to the project >> Committers - people who have commit access to the project's repo(s) >> Maintainers - volunteers from the pool of committers who have stepped >> forward to shepherd a single module. This is not a position of authority - >> but >> rather one of responsibility - to ensure coding standards are met, that >> accepted patches don't break things, etc. > So going into that, this is one area where I have difference opinion on > maintainer's responsibility. > > In the write-up, it says "Review, and potentially acceptance, of code changes > from the community. The maintainer is responsible for testing that new > contributions work and do not break the application, and that the code > changes are of high quality." > > I think the maintainer should be responsible for making sure the process from > feature design, code design, code review, to unit testing and integration > testing have been followed but I find that "testing that new contributions > work" to be challenging for a maintainer. I think the committers need to > prove as part of their patch that it doesn't break things. Maintainers can > go back and say "Well, you haven't proved this or that" and can give > suggestions on how to prove it. > > What do others think?
I think there's a balance to be made. The last thing I want is patches "thrown over the wall" - that will result in burning out maintainers pretty quickly and other things being thrown back at the contributors. At the same time, I expect a maintainer to (at least sometime) have better understanding of the module and CloudStack in general than a contributor does - thus I think the maintainer has a little more responsibility. Any thoughts on how other projects do this? Obviously thorough testing of a code change on something like CloudStack isn't a drop in the bucket (especially without a test suite) and I don't want to suggest that should be done for every patch, or we'll have no volunteers for maintainer roles... Throwing out an idea - could we mitigate this somewhat by suggesting a test-driven development model, or will that really scare folks away? John
