cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Kinsella <>
Subject Re: Maintainer/committer model for CloudStack
Date Wed, 16 May 2012 17:56:19 GMT
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
> 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?


View raw message