On Wed, May 16, 2012 at 1:09 PM, Chiradeep Vittal
<chiradeep.vit...@citrix.com> wrote:
>
>
> 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
>
In many ways the 'project manager' is encompassed in the release
manager role based on my reading - but is release specific rather than
project specific. Also - typically a project manager has some
authority, which largely doesn't exist here, and it's hard to compel
folks in a community like this.
--David
