On 5/15/12 11:39 PM, "David Nalley" <da...@gnsa.us> wrote:
>On Wed, May 16, 2012 at 12:38 AM, Alex Huang <alex.hu...@citrix.com>
>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?
>>
>> --Alex
>
>Makes sense to me - but I think we likely need to figure out what the
>barrier is to 'prove' - and naturally 'proving that nothing is broken'
>is practically impossible. Perhaps it's a sliding scale - small
>patches have to demonstrably fix the problem reported, large features
>must pass some BVT or something similar.
>
>Any others have comments?
>
>--David
Depending on the incoming rate of patches and features, it is quite
possible that the maintainers will be severely backlogged. This may have
the unfortunate consequence of discouraging contributors. If the
contributors realized that it was incumbent on them to get quality patches
and code in, then they might be more motivated to make it easier ("prove"
that it works) on the maintainer.
Another way might be to get 2 committers (maintainers or otherwise) to +1
the patch or feature, easing the review burden.
Still, it seems to me that it would be useful to have an official (or
semi-official) project manager for Apache CloudStack that can keep an eye
on the patch stream and the release schedule.
As others have said, automated {unit, integration, regression} tests will
ease everyone's burden.
--
Chiradeep
