You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by John Kinsella <jl...@stratosec.co> on 2012/05/04 06:24:19 UTC
Maintainer/committer model for CloudStack
Guys - during the developer on-ramp this week, we held a group discussion around the topics of reviewing patch submissions, code maintainers, voting, and overall care and management of the official source tree. We wanted to continue the discussion on the developer list to look for the best way to set this up for CloudStack and I volunteered to kick off the discussion.
For the overall scope of the discussion, I'm using "maintainer" to describe a person who has been given commit rights to trunk, and who reviews potential code modifications for inclusion into the CloudStack source. This is a separate responsibility from that of setting direction and priorities for the CS project. Just want to be clear. :)
I'm going to list out some of the points and goals we discussed, but this probably isn't a complete list of things we should be considering:
Goals:
* Responsive maintainer team that nurtures involvement from the community by providing friendly, useful, efficient responses to code modification submissions
* Responsibility vs authority - the goal is not to grant authority to maintain the codebase, but to culture responsibility and respect for the codebase and the community.
Points to consider:
* Maintainer scope: Is a maintainer responsible for certain parts of CS, or the overall codebase? As CS moves to a more modular architecture, maybe a maintainer focuses on a particular module? The concept of "super" maintainers was mentioned, a select group of people who have the ability to effect change across the entire code base. That one has such ability does not mean that it should be wielded often.
* Single or multiple maintainers: Be there a given scope for a module, sub-project, or whatever, CS could adopt a model of a single "ultimate" maintainer who has to do all reviews/commits, or a team of maintainers. The single person model provides "ultimate" responsibility for that scope and a more predictable response to submissions, while a team distributes the workload and minimizes the impact of a single person becoming sick/distracted/trapped under bus/etc.
* Code modification voting: General process for Apache projects is to vote +1/0/-1. Question is, when do we use this? It probably isn't necessary for a 3 line commit.
* Responsiveness to patch submissions: One option to ensure prompt response to patch submissions would be to have some form of guidance similar to "maintainers will review and respond to patch submissions within 5 days" (pick a number). This isn't really enforceable as the community is neither employed by nor reports to a single entity, although repeated failures to meet the guideline could result in removal from the maintainer position.
* Patch testing: It would be great to have a test suite for a maintainer to easily confirm that a patch does not inadvertently affect functionality/logic outside the intended scope of the patch
What have I left out? We referenced both the Linux (I can't find a good page describing their process?) and Drupal (http://drupal.org/contribute/core-maintainers) maintenance methods, but open to any others we can look at. Please give any thoughts on the subject, and definitely add any viewpoints/experiences/concepts that you may have.
Thanks!
John
Re: Maintainer/committer model for CloudStack
Posted by David Nalley <da...@gnsa.us>.
On Wed, May 16, 2012 at 2:31 PM, John Kinsella <jl...@stratosec.co> wrote:
> On May 15, 2012, at 9:21 PM, David Nalley wrote:
>> This is a discussion still - no need to move it away from this list IMO.
>>
>> John - thanks for writing this up.
>>
>> So there's a mixture of our own terminology and ASF terminology - and
>> I propose that we start with a lexicon, and here's what I'd suggest:
>>
>> 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.
>
> Is this statement valid?
>
> "In general, maintainers only have commit rights on the module for which they are responsible"
>
> Is CS going to manage commit rights at this level of granularity?
>
>
I would say no - committers have commit privs on the repo - we assume
that anyone who is elected as a committer is sane and not malicious,
and thus we trust them.
Re: Maintainer/committer model for CloudStack
Posted by John Kinsella <jl...@stratosec.co>.
On May 15, 2012, at 9:21 PM, David Nalley wrote:
> This is a discussion still - no need to move it away from this list IMO.
>
> John - thanks for writing this up.
>
> So there's a mixture of our own terminology and ASF terminology - and
> I propose that we start with a lexicon, and here's what I'd suggest:
>
> 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.
Is this statement valid?
"In general, maintainers only have commit rights on the module for which they are responsible"
Is CS going to manage commit rights at this level of granularity?
Re: Maintainer/committer model for CloudStack
Posted by David Nalley <da...@gnsa.us>.
On Wed, May 16, 2012 at 1:09 PM, Chiradeep Vittal
<Ch...@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 <Al...@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
Re: Maintainer/committer model for CloudStack
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 5/15/12 11:39 PM, "David Nalley" <da...@gnsa.us> wrote:
>On Wed, May 16, 2012 at 12:38 AM, Alex Huang <Al...@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
Re: Maintainer/committer model for CloudStack
Posted by David Nalley <da...@gnsa.us>.
On Wed, May 16, 2012 at 12:38 AM, Alex Huang <Al...@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
Re: Maintainer/committer model for CloudStack
Posted by Matthew Hartmann <mh...@tls.net>.
I believe the worst person to perform quality assurance on code is the
person who wrote the code. It would be best to have someone else who
didn't write the code to test and make sure the application and new code
are functional because they are going to be approaching it with fresh eyes.
Matthew Hartmann
/Systems Administrator | V: 812.378.4100 x 850 | E: mhartmann@tls.net/
TLS.NET, Inc.
http://www.tls.net
On 5/16/2012 12:38 AM, 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?
>
> --Alex
>
>
Re: Maintainer/committer model for CloudStack
Posted by Robert Schweikert <rj...@suse.com>.
On 05/16/2012 12:38 AM, 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 like this. Responsibility of testing a patch lies with the patch
submitter. If we make this the responsibility of the maintainer or
committer we will foster a "throw it over the wall" mentality that will
not be healthy in the long run. I do not think that this conflicts with
Dave's definitions.
That said, we also have to be reasonable what constitutes testing. Not
every contributor will be able to run a full test suite or test a given
patch in all possible scenarios. Thus the responsibility of testing is
really shared by many and not just the contributor - committer -
maintainer chain. But the initial responsibility must lie with the
contributor, IMHO.
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147
Re: Maintainer/committer model for CloudStack
Posted by John Kinsella <jl...@stratosec.co>.
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
RE: Maintainer/committer model for CloudStack
Posted by Alex Huang <Al...@citrix.com>.
> 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
Re: Maintainer/committer model for CloudStack
Posted by David Nalley <da...@gnsa.us>.
On Tue, May 15, 2012 at 10:14 PM, Alex Huang <Al...@citrix.com> wrote:
> John,
>
> Should we comment by replying to this email or by adding comments to your page?
>
> Also,
>
>> One question - we seem to have "committers" as well as "maintainers."
>> What's the difference between the two?
>
> To me, committers are contributors. Maintainers are gatekeepers to make sure the process and the design principals were followed before code is merged.
>
> --Alex
This is a discussion still - no need to move it away from this list IMO.
John - thanks for writing this up.
So there's a mixture of our own terminology and ASF terminology - and
I propose that we start with a lexicon, and here's what I'd suggest:
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.
--David
RE: Maintainer/committer model for CloudStack
Posted by Rajesh Battala <ra...@citrix.com>.
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Wednesday, May 16, 2012 7:45 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Maintainer/committer model for CloudStack
>
> John,
>
> Should we comment by replying to this email or by adding comments to your
> page?
>
> Also,
>
> > One question - we seem to have "committers" as well as "maintainers."
> > What's the difference between the two?
>
> To me, committers are contributors. Maintainers are gatekeepers to make
> sure the process and the design principals were followed before code is
> merged.
>
> --Alex
I too mean the same for comitters and maintainers.
RE: Maintainer/committer model for CloudStack
Posted by Alex Huang <Al...@citrix.com>.
John,
Should we comment by replying to this email or by adding comments to your page?
Also,
> One question - we seem to have "committers" as well as "maintainers."
> What's the difference between the two?
To me, committers are contributors. Maintainers are gatekeepers to make sure the process and the design principals were followed before code is merged.
--Alex
Re: Maintainer/committer model for CloudStack
Posted by Sheng Yang <sh...@yasker.org>.
On Fri, Jun 1, 2012 at 10:19 PM, Alena Prokharchyk
<Al...@citrix.com> wrote:
> On 6/1/12 7:57 PM, "David Nalley" <da...@gnsa.us> wrote:
>
>>So it seems we have some consensus around trying this maintainer model
>>out - so now we need the existing committers to step up for some of
>>these 'modules'. I am happy to step up for packaging stuff (debs and
>>rpms) and some of the related things around this such as initscripts.
>>I'd like to get to the point where someone else picks debian stuff up,
>>since my level of comfort and familiarity there is a bit lower.
>>
>>Others?
>>
>>--David
>>
>
>
>
>
> I can take over API module and share responsiblity with someone else on
> Network module (I'm not an expert when it comes to the backend scripts and
> network external devices - F5,Netscaler,Juniper)
I can share the work with Alena on network part, frontend and backend
of Virtual Router related things. But I am also not a expert on
external devices...
And I can take system vm template part as well.
--Sheng
>
> -Alena.
>
RE: Maintainer/committer model for CloudStack
Posted by Frank Zhang <Fr...@citrix.com>.
Sorry for late reply.
I'll take OVM/Baremetal and setup now.
> -----Original Message-----
> From: Jessica Tomechak [mailto:Jessica.Tomechak@citrix.com]
> Sent: Monday, June 04, 2012 1:33 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Maintainer/committer model for CloudStack
>
> I can maintain documentation.
>
> Jessica T.
> CloudStack Tech Pubs
>
>
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Friday, June 01, 2012 7:57 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Maintainer/committer model for CloudStack
>
> So it seems we have some consensus around trying this maintainer model
> out - so now we need the existing committers to step up for some of these
> 'modules'. I am happy to step up for packaging stuff (debs and
> rpms) and some of the related things around this such as initscripts.
> I'd like to get to the point where someone else picks debian stuff up, since
> my level of comfort and familiarity there is a bit lower.
>
> Others?
>
> --David
RE: Maintainer/committer model for CloudStack
Posted by Jessica Tomechak <Je...@citrix.com>.
I can maintain documentation.
Jessica T.
CloudStack Tech Pubs
-----Original Message-----
From: David Nalley [mailto:david@gnsa.us]
Sent: Friday, June 01, 2012 7:57 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Maintainer/committer model for CloudStack
So it seems we have some consensus around trying this maintainer model out - so now we need the existing committers to step up for some of these 'modules'. I am happy to step up for packaging stuff (debs and
rpms) and some of the related things around this such as initscripts.
I'd like to get to the point where someone else picks debian stuff up, since my level of comfort and familiarity there is a bit lower.
Others?
--David
RE: Maintainer/committer model for CloudStack
Posted by Prachi Damle <Pr...@citrix.com>.
I can take up the Deployment Planners/Allocator components, EC2 API (awsapi).
-Prachi
-----Original Message-----
From: David Nalley [mailto:david@gnsa.us]
Sent: Friday, June 01, 2012 7:57 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Maintainer/committer model for CloudStack
So it seems we have some consensus around trying this maintainer model out - so now we need the existing committers to step up for some of these 'modules'. I am happy to step up for packaging stuff (debs and
rpms) and some of the related things around this such as initscripts.
I'd like to get to the point where someone else picks debian stuff up, since my level of comfort and familiarity there is a bit lower.
Others?
--David
RE: Maintainer/committer model for CloudStack
Posted by Edison Su <Ed...@citrix.com>.
I can take up KVM part.
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Friday, June 01, 2012 7:57 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Maintainer/committer model for CloudStack
>
> So it seems we have some consensus around trying this maintainer model
> out - so now we need the existing committers to step up for some of
> these 'modules'. I am happy to step up for packaging stuff (debs and
> rpms) and some of the related things around this such as initscripts.
> I'd like to get to the point where someone else picks debian stuff up,
> since my level of comfort and familiarity there is a bit lower.
>
> Others?
>
> --David
RE: Maintainer/committer model for CloudStack
Posted by Abhinandan Prateek <Ab...@citrix.com>.
I will take LDAP, Amazon SNS (todo) and XCP.
Also interested in VM state sync and HA part of the middleware if these are considered 'modules'.
-abhi
>-----Original Message-----
>From: Kelven Yang [mailto:kelven.yang@citrix.com]
>Sent: Tuesday, June 12, 2012 7:43 AM
>To: cloudstack-dev@incubator.apache.org
>Subject: RE: Maintainer/committer model for CloudStack
>
>I'll take VMware and console proxy
>Kelven
>
>> -----Original Message-----
>> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
>> Sent: Monday, June 11, 2012 6:21 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: RE: Maintainer/committer model for CloudStack
>>
>> I'll take XenServer and snapshot parts.
>>
>> Regards,
>> Anthony
>>
>> > -----Original Message-----
>> > From: David Nalley [mailto:david@gnsa.us]
>> > Sent: Friday, June 01, 2012 7:57 PM
>> > To: cloudstack-dev@incubator.apache.org
>> > Subject: Re: Maintainer/committer model for CloudStack
>> >
>> > So it seems we have some consensus around trying this maintainer
>> > model out - so now we need the existing committers to step up for
>> > some of these 'modules'. I am happy to step up for packaging stuff
>> > (debs and
>> > rpms) and some of the related things around this such as initscripts.
>> > I'd like to get to the point where someone else picks debian stuff
>> > up, since my level of comfort and familiarity there is a bit lower.
>> >
>> > Others?
>> >
>> > --David
RE: Maintainer/committer model for CloudStack
Posted by Kelven Yang <ke...@citrix.com>.
I'll take VMware and console proxy
Kelven
> -----Original Message-----
> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> Sent: Monday, June 11, 2012 6:21 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Maintainer/committer model for CloudStack
>
> I'll take XenServer and snapshot parts.
>
> Regards,
> Anthony
>
> > -----Original Message-----
> > From: David Nalley [mailto:david@gnsa.us]
> > Sent: Friday, June 01, 2012 7:57 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: Maintainer/committer model for CloudStack
> >
> > So it seems we have some consensus around trying this maintainer model
> > out - so now we need the existing committers to step up for some of
> > these 'modules'. I am happy to step up for packaging stuff (debs and
> > rpms) and some of the related things around this such as initscripts.
> > I'd like to get to the point where someone else picks debian stuff up,
> > since my level of comfort and familiarity there is a bit lower.
> >
> > Others?
> >
> > --David
RE: Maintainer/committer model for CloudStack
Posted by Anthony Xu <Xu...@citrix.com>.
I'll take XenServer and snapshot parts.
Regards,
Anthony
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Friday, June 01, 2012 7:57 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Maintainer/committer model for CloudStack
>
> So it seems we have some consensus around trying this maintainer model
> out - so now we need the existing committers to step up for some of
> these 'modules'. I am happy to step up for packaging stuff (debs and
> rpms) and some of the related things around this such as initscripts.
> I'd like to get to the point where someone else picks debian stuff up,
> since my level of comfort and familiarity there is a bit lower.
>
> Others?
>
> --David
RE: Maintainer/committer model for CloudStack
Posted by Rajesh Battala <ra...@citrix.com>.
We can use http://jenkins.cloudstack.org/ for the same.
> -----Original Message-----
> From: Wido den Hollander [mailto:wido@widodh.nl]
> Sent: Saturday, June 02, 2012 5:37 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: David Nalley
> Subject: Re: Maintainer/committer model for CloudStack
>
>
>
> On 06/02/2012 04:57 AM, David Nalley wrote:
> > So it seems we have some consensus around trying this maintainer model
> > out - so now we need the existing committers to step up for some of
> > these 'modules'. I am happy to step up for packaging stuff (debs and
> > rpms) and some of the related things around this such as initscripts.
> > I'd like to get to the point where someone else picks debian stuff up,
> > since my level of comfort and familiarity there is a bit lower.
> >
>
> As I'm a heavy Ubuntu user I'd like to help with those packages. My goal is
> still to get WAF out of the door and build all the packages with ant and dpkg.
>
> It's still annoying me that the dependencies in the packages are not correct
> and they them getting build is a moving target.
>
> The build system should be so stable that we can have nightly rpm and deb
> builds of CloudStack somewhere on the website.
>
> Wido
>
> > Others?
> >
> > --David
Re: Maintainer/committer model for CloudStack
Posted by Wido den Hollander <wi...@widodh.nl>.
On 06/02/2012 04:57 AM, David Nalley wrote:
> So it seems we have some consensus around trying this maintainer model
> out - so now we need the existing committers to step up for some of
> these 'modules'. I am happy to step up for packaging stuff (debs and
> rpms) and some of the related things around this such as initscripts.
> I'd like to get to the point where someone else picks debian stuff up,
> since my level of comfort and familiarity there is a bit lower.
>
As I'm a heavy Ubuntu user I'd like to help with those packages. My goal
is still to get WAF out of the door and build all the packages with ant
and dpkg.
It's still annoying me that the dependencies in the packages are not
correct and they them getting build is a moving target.
The build system should be so stable that we can have nightly rpm and
deb builds of CloudStack somewhere on the website.
Wido
> Others?
>
> --David
Re: Maintainer/committer model for CloudStack
Posted by Robert Schweikert <rj...@suse.com>.
On 06/12/2012 07:45 PM, Will Chan wrote:
> I've taken all the feedback so far and extended the CloudStack Maintainers Guide written by John and added all the maintainers so far. There are probably more missing but that's what we have today. If we want this list to be its own page, we can certainly do that as well but I thought it was easier to see what a maintainer's role of CloudStack is and who they are currently all in a single page.
>
> http://wiki.cloudstack.org/display/COMM/Draft%3A+CloudStack+Maintainers+Guide
Looks good to me.
I think it would be nice to have a couple of sentences providing a
guideline when fixes will be applied to a release branch. At this point
the page only states that fixes will be applied to trunk. However, I can
imagine some scenarios where a fix in a release branch is
warranted/really useful.
- security issue
- annoying bug that almost everyone hits
- bug that is not necessarily annoying but has no work-around and
effects expected functionality
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147
RE: Maintainer/committer model for CloudStack
Posted by Will Chan <wi...@citrix.com>.
I agree. I know Wido has but that's about the only one that has raised their hand in volunteering to be a maintainer. The hope is that the current maintainers can be phased out as soon as more patches have been submitted and more committers can be voted in to help with this.
Will
________________________________________
From: John Kinsella [jlk@stratosec.co]
Sent: Tuesday, June 12, 2012 5:44 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Maintainer/committer model for CloudStack
Thanks Will, I was thinking of doing similar.
I haven't raised a hand to be a maintainer as I don't think I know any of the modules well enough to take that roll yet, but it would be nice to see a few more non-citrix people involved...
John
On Jun 12, 2012, at 4:45 PM, Will Chan wrote:
> I've taken all the feedback so far and extended the CloudStack Maintainers Guide written by John and added all the maintainers so far. There are probably more missing but that's what we have today. If we want this list to be its own page, we can certainly do that as well but I thought it was easier to see what a maintainer's role of CloudStack is and who they are currently all in a single page.
>
> http://wiki.cloudstack.org/display/COMM/Draft%3A+CloudStack+Maintainers+Guide
>
> Will
>
>> -----Original Message-----
>> From: David Nalley [mailto:david@gnsa.us]
>> Sent: Friday, June 01, 2012 7:57 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: Maintainer/committer model for CloudStack
>>
>> So it seems we have some consensus around trying this maintainer model out -
>> so now we need the existing committers to step up for some of these 'modules'.
>> I am happy to step up for packaging stuff (debs and
>> rpms) and some of the related things around this such as initscripts.
>> I'd like to get to the point where someone else picks debian stuff up, since my
>> level of comfort and familiarity there is a bit lower.
>>
>> Others?
>>
>> --David
Stratosec - Secure Infrastructure as a Service
o: 415.315.9385
@johnlkinsella
Re: Maintainer/committer model for CloudStack
Posted by John Kinsella <jl...@stratosec.co>.
Thanks Will, I was thinking of doing similar.
I haven't raised a hand to be a maintainer as I don't think I know any of the modules well enough to take that roll yet, but it would be nice to see a few more non-citrix people involved...
John
On Jun 12, 2012, at 4:45 PM, Will Chan wrote:
> I've taken all the feedback so far and extended the CloudStack Maintainers Guide written by John and added all the maintainers so far. There are probably more missing but that's what we have today. If we want this list to be its own page, we can certainly do that as well but I thought it was easier to see what a maintainer's role of CloudStack is and who they are currently all in a single page.
>
> http://wiki.cloudstack.org/display/COMM/Draft%3A+CloudStack+Maintainers+Guide
>
> Will
>
>> -----Original Message-----
>> From: David Nalley [mailto:david@gnsa.us]
>> Sent: Friday, June 01, 2012 7:57 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: Maintainer/committer model for CloudStack
>>
>> So it seems we have some consensus around trying this maintainer model out -
>> so now we need the existing committers to step up for some of these 'modules'.
>> I am happy to step up for packaging stuff (debs and
>> rpms) and some of the related things around this such as initscripts.
>> I'd like to get to the point where someone else picks debian stuff up, since my
>> level of comfort and familiarity there is a bit lower.
>>
>> Others?
>>
>> --David
Stratosec - Secure Infrastructure as a Service
o: 415.315.9385
@johnlkinsella
RE: Maintainer/committer model for CloudStack
Posted by Kevin Kluge <Ke...@citrix.com>.
Can we have the maintainers take responsibility for the incoming patch stream right away?
-kevin
> -----Original Message-----
> From: Will Chan [mailto:will.chan@citrix.com]
> Sent: Tuesday, June 12, 2012 4:46 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Maintainer/committer model for CloudStack
>
> I've taken all the feedback so far and extended the CloudStack Maintainers
> Guide written by John and added all the maintainers so far. There are
> probably more missing but that's what we have today. If we want this list to
> be its own page, we can certainly do that as well but I thought it was easier to
> see what a maintainer's role of CloudStack is and who they are currently all in
> a single page.
>
> http://wiki.cloudstack.org/display/COMM/Draft%3A+CloudStack+Maintainer
> s+Guide
>
> Will
>
> > -----Original Message-----
> > From: David Nalley [mailto:david@gnsa.us]
> > Sent: Friday, June 01, 2012 7:57 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: Maintainer/committer model for CloudStack
> >
> > So it seems we have some consensus around trying this maintainer model
> > out - so now we need the existing committers to step up for some of these
> 'modules'.
> > I am happy to step up for packaging stuff (debs and
> > rpms) and some of the related things around this such as initscripts.
> > I'd like to get to the point where someone else picks debian stuff up,
> > since my level of comfort and familiarity there is a bit lower.
> >
> > Others?
> >
> > --David
RE: Maintainer/committer model for CloudStack
Posted by Will Chan <wi...@citrix.com>.
I've taken all the feedback so far and extended the CloudStack Maintainers Guide written by John and added all the maintainers so far. There are probably more missing but that's what we have today. If we want this list to be its own page, we can certainly do that as well but I thought it was easier to see what a maintainer's role of CloudStack is and who they are currently all in a single page.
http://wiki.cloudstack.org/display/COMM/Draft%3A+CloudStack+Maintainers+Guide
Will
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Friday, June 01, 2012 7:57 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Maintainer/committer model for CloudStack
>
> So it seems we have some consensus around trying this maintainer model out -
> so now we need the existing committers to step up for some of these 'modules'.
> I am happy to step up for packaging stuff (debs and
> rpms) and some of the related things around this such as initscripts.
> I'd like to get to the point where someone else picks debian stuff up, since my
> level of comfort and familiarity there is a bit lower.
>
> Others?
>
> --David
Re: Maintainer/committer model for CloudStack
Posted by Alena Prokharchyk <Al...@citrix.com>.
On 6/1/12 7:57 PM, "David Nalley" <da...@gnsa.us> wrote:
>So it seems we have some consensus around trying this maintainer model
>out - so now we need the existing committers to step up for some of
>these 'modules'. I am happy to step up for packaging stuff (debs and
>rpms) and some of the related things around this such as initscripts.
>I'd like to get to the point where someone else picks debian stuff up,
>since my level of comfort and familiarity there is a bit lower.
>
>Others?
>
>--David
>
I can take over API module and share responsiblity with someone else on
Network module (I'm not an expert when it comes to the backend scripts and
network external devices - F5,Netscaler,Juniper)
-Alena.
Re: Maintainer/committer model for CloudStack
Posted by David Nalley <da...@gnsa.us>.
So it seems we have some consensus around trying this maintainer model
out - so now we need the existing committers to step up for some of
these 'modules'. I am happy to step up for packaging stuff (debs and
rpms) and some of the related things around this such as initscripts.
I'd like to get to the point where someone else picks debian stuff up,
since my level of comfort and familiarity there is a bit lower.
Others?
--David
Re: Maintainer/committer model for CloudStack
Posted by David Nalley <da...@gnsa.us>.
On Thu, May 17, 2012 at 2:08 AM, Chiradeep Vittal
<Ch...@citrix.com> wrote:
>
>
> On 5/16/12 11:33 AM, "John Kinsella" <jl...@stratosec.co> wrote:
>
>>On May 16, 2012, at 5:33 AM, Robert Schweikert wrote:
>>> On 05/15/2012 10:08 PM, John Kinsella wrote:
>>>> OK - took a little longer than intended, but I've got a draft put
>>>>together. I can keep adding to this, but wanted to get it out for
>>>>comments on what's written so far.
>>>>
>>>> One question - we seem to have "committers" as well as "maintainers."
>>>>What's the difference between the two?
>>>>
>>>> I'm trying to reach a balance between an informal document and
>>>>something as structured as the Linux development process (see the Linux
>>>>Foundation link in the appendix). If people want to see more formality
>>>>and structure, let me know.
>>>>
>>>> Please review what I have so far and share thoughts with the list.
>>>>Thanks. :)
>>>>
>>>>
>>>>http://wiki.cloudstack.org/display/COMM/Draft%3A+CloudStack+Maintainers+
>>>>Guide (or http://wiki.cloudstack.org/x/MIB9)
>>>[snip]
>>
>>> 3.) Being an ASF project I take it CS will use Jira, I think there
>>>should be a link to Jira in the Patch Submission section. Also it should
>>>be more clearly stated that feature requests also need to be entered in
>>>Jira, rather than just stating they should be documented.
>>
>>Yep, I left out a few links as various functionality (new wiki, jira,
>>etc) are not yet in place. Voting and release management can be greatly
>>expanded, but wanted to get the other parts in place first.
>
> Any thoughts on using a review tool like Gerrit [1] or Phabricator [2] as
> a front-end to git? Would that work in the Apache infrastructure?
>
> [1] http://code.google.com/p/gerrit/
> [2] http://phabricator.org/
>
> --
> Chiradeep
>
Apache has reviewboard up - http://reviews.apache.org
--David
Re: Maintainer/committer model for CloudStack
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 5/16/12 11:33 AM, "John Kinsella" <jl...@stratosec.co> wrote:
>On May 16, 2012, at 5:33 AM, Robert Schweikert wrote:
>> On 05/15/2012 10:08 PM, John Kinsella wrote:
>>> OK - took a little longer than intended, but I've got a draft put
>>>together. I can keep adding to this, but wanted to get it out for
>>>comments on what's written so far.
>>>
>>> One question - we seem to have "committers" as well as "maintainers."
>>>What's the difference between the two?
>>>
>>> I'm trying to reach a balance between an informal document and
>>>something as structured as the Linux development process (see the Linux
>>>Foundation link in the appendix). If people want to see more formality
>>>and structure, let me know.
>>>
>>> Please review what I have so far and share thoughts with the list.
>>>Thanks. :)
>>>
>>>
>>>http://wiki.cloudstack.org/display/COMM/Draft%3A+CloudStack+Maintainers+
>>>Guide (or http://wiki.cloudstack.org/x/MIB9)
>>[snip]
>
>> 3.) Being an ASF project I take it CS will use Jira, I think there
>>should be a link to Jira in the Patch Submission section. Also it should
>>be more clearly stated that feature requests also need to be entered in
>>Jira, rather than just stating they should be documented.
>
>Yep, I left out a few links as various functionality (new wiki, jira,
>etc) are not yet in place. Voting and release management can be greatly
>expanded, but wanted to get the other parts in place first.
Any thoughts on using a review tool like Gerrit [1] or Phabricator [2] as
a front-end to git? Would that work in the Apache infrastructure?
[1] http://code.google.com/p/gerrit/
[2] http://phabricator.org/
--
Chiradeep
Re: Maintainer/committer model for CloudStack
Posted by John Kinsella <jl...@stratosec.co>.
On May 16, 2012, at 5:33 AM, Robert Schweikert wrote:
> On 05/15/2012 10:08 PM, John Kinsella wrote:
>> OK - took a little longer than intended, but I've got a draft put together. I can keep adding to this, but wanted to get it out for comments on what's written so far.
>>
>> One question - we seem to have "committers" as well as "maintainers." What's the difference between the two?
>>
>> I'm trying to reach a balance between an informal document and something as structured as the Linux development process (see the Linux Foundation link in the appendix). If people want to see more formality and structure, let me know.
>>
>> Please review what I have so far and share thoughts with the list. Thanks. :)
>>
>> http://wiki.cloudstack.org/display/COMM/Draft%3A+CloudStack+Maintainers+Guide (or http://wiki.cloudstack.org/x/MIB9)
> Generally I think this is well written. A few comments:
> 1.) While reading I hit a couple of places that hit me as "maintainers are really special and outside the community". I think this is not the impression we would want to give. For me this was mostly triggered by wording such as "...interact with the community on development...". I think this could be softened by something like this ""...interact with other members of the community on development...". This is a bit of nit pick, I know ;)
I've word-smithed that a little more. :)
> 2.) In the branching section there is a sentence detailing that defects are fixed in the trunk. IMHO, there should be a provision to fix defects in the release branch as well.
This was on my mind - I believe(?) currently CS uses a linear development model of updates are applied to HEAD only? Otherwise we switch into a maintainer model of the last X major releases will be maintained for Y months. Adds a bit of complexity, but I'm sure some folks would greatly appreciate.
> 3.) Being an ASF project I take it CS will use Jira, I think there should be a link to Jira in the Patch Submission section. Also it should be more clearly stated that feature requests also need to be entered in Jira, rather than just stating they should be documented.
Yep, I left out a few links as various functionality (new wiki, jira, etc) are not yet in place. Voting and release management can be greatly expanded, but wanted to get the other parts in place first.
> 4.) One thing that is missing in the document is a statement about releases. Releases, IMHO, are part of the Development work flow. In the release section the document could then also state the policy on defect fixes in a release branch.
Think we're on the same page - I'll go ahead and add this in later today. If others have thoughts around branch maintenance, do share!
John
Re: Maintainer/committer model for CloudStack
Posted by Robert Schweikert <rj...@suse.com>.
On 05/15/2012 10:08 PM, John Kinsella wrote:
> OK - took a little longer than intended, but I've got a draft put together. I can keep adding to this, but wanted to get it out for comments on what's written so far.
>
> One question - we seem to have "committers" as well as "maintainers." What's the difference between the two?
>
> I'm trying to reach a balance between an informal document and something as structured as the Linux development process (see the Linux Foundation link in the appendix). If people want to see more formality and structure, let me know.
>
> Please review what I have so far and share thoughts with the list. Thanks. :)
>
> http://wiki.cloudstack.org/display/COMM/Draft%3A+CloudStack+Maintainers+Guide (or http://wiki.cloudstack.org/x/MIB9)
Generally I think this is well written. A few comments:
1.) While reading I hit a couple of places that hit me as "maintainers
are really special and outside the community". I think this is not the
impression we would want to give. For me this was mostly triggered by
wording such as "...interact with the community on development...". I
think this could be softened by something like this ""...interact with
other members of the community on development...". This is a bit of nit
pick, I know ;)
2.) In the branching section there is a sentence detailing that defects
are fixed in the trunk. IMHO, there should be a provision to fix defects
in the release branch as well.
3.) Being an ASF project I take it CS will use Jira, I think there
should be a link to Jira in the Patch Submission section. Also it should
be more clearly stated that feature requests also need to be entered in
Jira, rather than just stating they should be documented.
4.) One thing that is missing in the document is a statement about
releases. Releases, IMHO, are part of the Development work flow. In the
release section the document could then also state the policy on defect
fixes in a release branch.
Later,
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147
Re: Maintainer/committer model for CloudStack
Posted by John Kinsella <jl...@stratosec.co>.
OK - took a little longer than intended, but I've got a draft put together. I can keep adding to this, but wanted to get it out for comments on what's written so far.
One question - we seem to have "committers" as well as "maintainers." What's the difference between the two?
I'm trying to reach a balance between an informal document and something as structured as the Linux development process (see the Linux Foundation link in the appendix). If people want to see more formality and structure, let me know.
Please review what I have so far and share thoughts with the list. Thanks. :)
http://wiki.cloudstack.org/display/COMM/Draft%3A+CloudStack+Maintainers+Guide (or http://wiki.cloudstack.org/x/MIB9)
John
ps - I went back and forth on the naming of this doc, between "CloudStack Maintainers Guide" and "CloudStack Contributors Guide." For now I'm using CS Maintainers Guide, to focus the efforts. I think eventually we need a single document or wiki section that covers a good selection of topics for a new developer - creating bugs, setting up the dev environment, coding style/code quality, documentation, patch submission, probably lots of others.
Re: Maintainer/committer model for CloudStack
Posted by Matt Domsch <Ma...@dell.com>.
On Fri, May 04, 2012 at 10:37:10AM -0500, David Nalley wrote:
> On Fri, May 4, 2012 at 12:24 AM, John Kinsella <jl...@stratosec.co> wrote:
> > I'm going to list out some of the points and goals we discussed, but this probably isn't a complete list of things we should be considering:
> >
> > Goals:
> > * Responsive maintainer team that nurtures involvement from the
> > community by providing friendly, useful, efficient responses to
> > code modification submissions
> > * Responsibility vs authority - the goal is not to grant
> > authority to maintain the codebase, but to culture responsibility
> > and respect for the codebase and the community.
> >
> > Points to consider:
> >
> > * Maintainer scope: Is a maintainer responsible for certain parts
> > of CS, or the overall codebase? As CS moves to a more modular
> > architecture, maybe a maintainer focuses on a particular module?
> > The concept of "super" maintainers was mentioned, a select group
> > of people who have the ability to effect change across the entire
> > code base. That one has such ability does not mean that it should
> > be wielded often.
As David pointed out in the live conversation, Fedora has done well
with this "provenpackager" model, where some long-term contributors
who do work all over the tree (or to many packages) can be granted the
right to change (nearly) any package. As long as the people granted
this power recognize the awesome responsibility it provides, and treat
it appropriately, it works quite well while providing the flexibility
to "get things done" that otherwise would languish waiting on tens of
other individuals to do their small part. I would want to see CS
retain this capability, though used sparingly.
> > * Single or multiple maintainers: Be there a given scope for a
> > module, sub-project, or whatever, CS could adopt a model of a
> > single "ultimate" maintainer who has to do all reviews/commits, or
> > a team of maintainers. The single person model provides "ultimate"
> > responsibility for that scope and a more predictable response to
> > submissions, while a team distributes the workload and minimizes
> > the impact of a single person becoming sick/distracted/trapped
> > under bus/etc.
To me, it's not about the number of maintainers of a given module
(only 1, no more than N, ...), it's that each maintainer treat the
role with the respect it deserves, and can work well with the rest of
the maintainers. David used the word "responsibility" - and I agree.
A strong sense of ownership, of responsibility to the other developers
and the user community, that the code will work, be of high quality,
will be open to suggestions and patches from non-maintainers, and can
mentor non-maintainers into productive recurring contributors or
maintainers going forward.
> > * Code modification voting: General process for Apache projects is
> > to vote +1/0/-1. Question is, when do we use this? It probably
> > isn't necessary for a 3 line commit.
There are 2 parts here: 1) who is the voting audience; 2) what are the
criteria necessary to invoke a vote? If the above maintainer
ownership responsibility is handled appropriately, there should be no
need for explicit votes (and certainly not for each patch or even
minor patch series). I'd prefer to see consensus develop for feature
and architecture direction, and leave voting out as much as possible.
Voting for PMC members etc. is appropriate of course, and should be
from a wide audience. I still need to understand how Apache
membership works in detail, but at a glance, that seems overly
restrictive. Again looking at Fedodra, we use a "Signed CLA +
contributor to one other group" as the voter pool. We could look at
something similar for CS.
> > * Responsiveness to patch submissions: One option to ensure
> > prompt response to patch submissions would be to have some form of
> > guidance similar to "maintainers will review and respond to patch
> > submissions within 5 days" (pick a number). This isn't really
> > enforceable as the community is neither employed by nor reports to
> > a single entity, although repeated failures to meet the guideline
> > could result in removal from the maintainer position.
comments within 2 weeks from a maintainer seems appropriate.
application/rejection may not be given other workflows into the tree
and other maintainer responsibilities elsewhere. Certainly a worthy goal.
> > * Patch testing: It would be great to have a test suite for a
> > maintainer to easily confirm that a patch does not inadvertently
> > affect functionality/logic outside the intended scope of the patch
and for the contributor. :-)
> Thanks for starting the discussion John and bringing all of this back
> to the mailing list.
>
> I am a fan of the module maintainer method - but I think that it has
> some weaknesses - not necessarily unworkable, but things we should at
> least acknowledge if we think module maintainer is the way we begin to
> handle things. Namely:
>
> * Tends to result in SPOF - may need some mitigation strategies.
With the above (min 1 maintainer /module + developers with global
commit power) can mitigate this to a large extent I think. Any more
than that and you're optimizing for what should be a rare occurance.
> * Need to ensure that it's not seen as authority or a place where
> decisions are made, but rather as a place of responsibility - with
> those responsibilities being the occasionally competing demands of
> getting changes in and maintaining quality.
+1
> * This needs to be rotated regularly
by some definition of regularly, perhaps. Once we decide on the
qualifications for a maintainer, it should be pretty obvious what a
reasonable timeframe for the role will be.
> I am also interested in some other workflow pieces. How do we do
> feature development (topic branches in git strike me as a good idea),
> how do we handle patches, etc.
+1 to topic branches and private git trees to pull from.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
Re: Maintainer/committer model for CloudStack
Posted by Edison Su <Ed...@citrix.com>.
On May 7, 2012, at 11:06 AM, Frank Zhang wrote:
>>
>> On May 4, 2012, at 8:37 AM, David Nalley wrote:
>>> On Fri, May 4, 2012 at 12:24 AM, John Kinsella <jl...@stratosec.co> wrote:
>>>> Guys - during the developer on-ramp this week, we held a group
>> discussion around the topics of reviewing patch submissions, code
>> maintainers, voting, and overall care and management of the official source
>> tree. We wanted to continue the discussion on the developer list to look for
>> the best way to set this up for CloudStack and I volunteered to kick off the
>> discussion.
>>>>
>>>> For the overall scope of the discussion, I'm using "maintainer" to
>>>> describe a person who has been given commit rights to trunk, and who
>>>> reviews potential code modifications for inclusion into the
>>>> CloudStack source. This is a separate responsibility from that of
>>>> setting direction and priorities for the CS project. Just want to be
>>>> clear. :)
>>>>
>>>> I'm going to list out some of the points and goals we discussed, but this
>> probably isn't a complete list of things we should be considering:
>>>>
>>>> Goals:
>>>> * Responsive maintainer team that nurtures involvement from the
>>>> community by providing friendly, useful, efficient responses to code
>>>> modification submissions
>>>> * Responsibility vs authority - the goal is not to grant authority to maintain
>> the codebase, but to culture responsibility and respect for the codebase and
>> the community.
>>>>
>>>> Points to consider:
>>>> * Maintainer scope: Is a maintainer responsible for certain parts of CS, or
>> the overall codebase? As CS moves to a more modular architecture, maybe a
>> maintainer focuses on a particular module? The concept of "super"
>> maintainers was mentioned, a select group of people who have the ability to
>> effect change across the entire code base. That one has such ability does not
>> mean that it should be wielded often.
>>>> * Single or multiple maintainers: Be there a given scope for a module,
>> sub-project, or whatever, CS could adopt a model of a single "ultimate"
>> maintainer who has to do all reviews/commits, or a team of maintainers. The
>> single person model provides "ultimate" responsibility for that scope and a
>> more predictable response to submissions, while a team distributes the
>> workload and minimizes the impact of a single person becoming
>> sick/distracted/trapped under bus/etc.
>
> I also agree the model of maintainer of module. One maintainer for each module should be good enough
> but there must be another person having privilege to commit patch in case the maintainer is travelling or on vacation.
> The super maintainer who has knowledge of the whole system needs not to involve in daily patches committing work,
> once there is a big patch that crosses multiple sub modules, super maintainer joins in discussion to help sub maintainer
> to identify if the patch is good enough to check in.
Never send a big patch that changes multiple modules, separate into multiple small patches instead, make maintainer's life easier.
>
>>>> * Code modification voting: General process for Apache projects is to
>> vote +1/0/-1. Question is, when do we use this? It probably isn't necessary
>> for a 3 line commit.
>
> For developing a new feature, I am sure in addition to maintainer there would be quite a few people joining in
> vote or discussion. For bug fix especially small bug fix, if no others throw out opposed idea, maintainer can
> commit the patch directly if he agrees with it
>
>>>> * Responsiveness to patch submissions: One option to ensure prompt
>> response to patch submissions would be to have some form of guidance
>> similar to "maintainers will review and respond to patch submissions within 5
>> days" (pick a number). This isn't really enforceable as the community is
>> neither employed by nor reports to a single entity, although repeated
>> failures to meet the guideline could result in removal from the maintainer
>> position.
>>>> * Patch testing: It would be great to have a test suite for a
>>>> maintainer to easily confirm that a patch does not inadvertently
>>>> affect functionality/logic outside the intended scope of the patch
>
> Absolutely.
>
>>>>
>>>> What have I left out? We referenced both the Linux (I can't find a good
>> page describing their process?) and Drupal
>> (http://drupal.org/contribute/core-maintainers) maintenance methods, but
>> open to any others we can look at. Please give any thoughts on the subject,
>> and definitely add any viewpoints/experiences/concepts that you may have.
>>>>
>>>> Thanks!
>>>>
>>>> John
>>>
>>> Thanks for starting the discussion John and bringing all of this back
>>> to the mailing list.
>>>
>>> I am a fan of the module maintainer method - but I think that it has
>>> some weaknesses - not necessarily unworkable, but things we should at
>>> least acknowledge if we think module maintainer is the way we begin to
>>> handle things. Namely:
>>>
>>> * Tends to result in SPOF - may need some mitigation strategies.
>>
>> What might work is for smaller or less critical modules a single maintainer is
>> OK, but PMC has ability to specify certain modules have multiple maintainers?
>> That could provide flexibility to minimize overhead on some parts. Wouldn't
>> want to make a module seem less important, though...
>>
>>> * Need to ensure that it's not seen as authority or a place where
>>> decisions are made, but rather as a place of responsibility - with
>>> those responsibilities being the occasionally competing demands of
>>> getting changes in and maintaining quality.
>>> * This needs to be rotated regularly
>>
>> I'm not sure about the regular rotation part - when I think of the large OSS
>> projects, the maintainers have been in place for years...rotation requires
>> getting somebody else up to speed?
>>
>>> Of course, at best, these could only be informal rules - any committer
>>> could commit to anything in the repo.
>>>
>>> Anyone want to draft a proposal for us to try out?
>>
>> I'm willing to take a stab, happy to work with others...
>>
>>> I am also interested in some other workflow pieces. How do we do
>>> feature development (topic branches in git strike me as a good idea),
>>> how do we handle patches, etc.
>>
>>
>> Sorry, I left this off the initial email, wasn't sure if it was within scope of the
>> discussion. Browsing through https://git-wip-us.apache.org/repos/asf, it
>> looks like most projects branch either for feature dev or version branches...
>>
>> Just found http://incubator.apache.org/isis/docbkx/html/guide/pt03.html
>> while browsing - I can see borrowing from that. :) Voting on releases also
>> makes sense.
>>
>> John
>
RE: Maintainer/committer model for CloudStack
Posted by Frank Zhang <Fr...@citrix.com>.
>
> On May 4, 2012, at 8:37 AM, David Nalley wrote:
> > On Fri, May 4, 2012 at 12:24 AM, John Kinsella <jl...@stratosec.co> wrote:
> >> Guys - during the developer on-ramp this week, we held a group
> discussion around the topics of reviewing patch submissions, code
> maintainers, voting, and overall care and management of the official source
> tree. We wanted to continue the discussion on the developer list to look for
> the best way to set this up for CloudStack and I volunteered to kick off the
> discussion.
> >>
> >> For the overall scope of the discussion, I'm using "maintainer" to
> >> describe a person who has been given commit rights to trunk, and who
> >> reviews potential code modifications for inclusion into the
> >> CloudStack source. This is a separate responsibility from that of
> >> setting direction and priorities for the CS project. Just want to be
> >> clear. :)
> >>
> >> I'm going to list out some of the points and goals we discussed, but this
> probably isn't a complete list of things we should be considering:
> >>
> >> Goals:
> >> * Responsive maintainer team that nurtures involvement from the
> >> community by providing friendly, useful, efficient responses to code
> >> modification submissions
> >> * Responsibility vs authority - the goal is not to grant authority to maintain
> the codebase, but to culture responsibility and respect for the codebase and
> the community.
> >>
> >> Points to consider:
> >> * Maintainer scope: Is a maintainer responsible for certain parts of CS, or
> the overall codebase? As CS moves to a more modular architecture, maybe a
> maintainer focuses on a particular module? The concept of "super"
> maintainers was mentioned, a select group of people who have the ability to
> effect change across the entire code base. That one has such ability does not
> mean that it should be wielded often.
> >> * Single or multiple maintainers: Be there a given scope for a module,
> sub-project, or whatever, CS could adopt a model of a single "ultimate"
> maintainer who has to do all reviews/commits, or a team of maintainers. The
> single person model provides "ultimate" responsibility for that scope and a
> more predictable response to submissions, while a team distributes the
> workload and minimizes the impact of a single person becoming
> sick/distracted/trapped under bus/etc.
I also agree the model of maintainer of module. One maintainer for each module should be good enough
but there must be another person having privilege to commit patch in case the maintainer is travelling or on vacation.
The super maintainer who has knowledge of the whole system needs not to involve in daily patches committing work,
once there is a big patch that crosses multiple sub modules, super maintainer joins in discussion to help sub maintainer
to identify if the patch is good enough to check in.
> >> * Code modification voting: General process for Apache projects is to
> vote +1/0/-1. Question is, when do we use this? It probably isn't necessary
> for a 3 line commit.
For developing a new feature, I am sure in addition to maintainer there would be quite a few people joining in
vote or discussion. For bug fix especially small bug fix, if no others throw out opposed idea, maintainer can
commit the patch directly if he agrees with it
> >> * Responsiveness to patch submissions: One option to ensure prompt
> response to patch submissions would be to have some form of guidance
> similar to "maintainers will review and respond to patch submissions within 5
> days" (pick a number). This isn't really enforceable as the community is
> neither employed by nor reports to a single entity, although repeated
> failures to meet the guideline could result in removal from the maintainer
> position.
> >> * Patch testing: It would be great to have a test suite for a
> >> maintainer to easily confirm that a patch does not inadvertently
> >> affect functionality/logic outside the intended scope of the patch
Absolutely.
> >>
> >> What have I left out? We referenced both the Linux (I can't find a good
> page describing their process?) and Drupal
> (http://drupal.org/contribute/core-maintainers) maintenance methods, but
> open to any others we can look at. Please give any thoughts on the subject,
> and definitely add any viewpoints/experiences/concepts that you may have.
> >>
> >> Thanks!
> >>
> >> John
> >
> > Thanks for starting the discussion John and bringing all of this back
> > to the mailing list.
> >
> > I am a fan of the module maintainer method - but I think that it has
> > some weaknesses - not necessarily unworkable, but things we should at
> > least acknowledge if we think module maintainer is the way we begin to
> > handle things. Namely:
> >
> > * Tends to result in SPOF - may need some mitigation strategies.
>
> What might work is for smaller or less critical modules a single maintainer is
> OK, but PMC has ability to specify certain modules have multiple maintainers?
> That could provide flexibility to minimize overhead on some parts. Wouldn't
> want to make a module seem less important, though...
>
> > * Need to ensure that it's not seen as authority or a place where
> > decisions are made, but rather as a place of responsibility - with
> > those responsibilities being the occasionally competing demands of
> > getting changes in and maintaining quality.
> > * This needs to be rotated regularly
>
> I'm not sure about the regular rotation part - when I think of the large OSS
> projects, the maintainers have been in place for years...rotation requires
> getting somebody else up to speed?
>
> > Of course, at best, these could only be informal rules - any committer
> > could commit to anything in the repo.
> >
> > Anyone want to draft a proposal for us to try out?
>
> I'm willing to take a stab, happy to work with others...
>
> > I am also interested in some other workflow pieces. How do we do
> > feature development (topic branches in git strike me as a good idea),
> > how do we handle patches, etc.
>
>
> Sorry, I left this off the initial email, wasn't sure if it was within scope of the
> discussion. Browsing through https://git-wip-us.apache.org/repos/asf, it
> looks like most projects branch either for feature dev or version branches...
>
> Just found http://incubator.apache.org/isis/docbkx/html/guide/pt03.html
> while browsing - I can see borrowing from that. :) Voting on releases also
> makes sense.
>
> John
Re: Maintainer/committer model for CloudStack
Posted by John Kinsella <jl...@stratosec.co>.
On May 4, 2012, at 8:37 AM, David Nalley wrote:
> On Fri, May 4, 2012 at 12:24 AM, John Kinsella <jl...@stratosec.co> wrote:
>> Guys - during the developer on-ramp this week, we held a group discussion around the topics of reviewing patch submissions, code maintainers, voting, and overall care and management of the official source tree. We wanted to continue the discussion on the developer list to look for the best way to set this up for CloudStack and I volunteered to kick off the discussion.
>>
>> For the overall scope of the discussion, I'm using "maintainer" to describe a person who has been given commit rights to trunk, and who reviews potential code modifications for inclusion into the CloudStack source. This is a separate responsibility from that of setting direction and priorities for the CS project. Just want to be clear. :)
>>
>> I'm going to list out some of the points and goals we discussed, but this probably isn't a complete list of things we should be considering:
>>
>> Goals:
>> * Responsive maintainer team that nurtures involvement from the community by providing friendly, useful, efficient responses to code modification submissions
>> * Responsibility vs authority - the goal is not to grant authority to maintain the codebase, but to culture responsibility and respect for the codebase and the community.
>>
>> Points to consider:
>> * Maintainer scope: Is a maintainer responsible for certain parts of CS, or the overall codebase? As CS moves to a more modular architecture, maybe a maintainer focuses on a particular module? The concept of "super" maintainers was mentioned, a select group of people who have the ability to effect change across the entire code base. That one has such ability does not mean that it should be wielded often.
>> * Single or multiple maintainers: Be there a given scope for a module, sub-project, or whatever, CS could adopt a model of a single "ultimate" maintainer who has to do all reviews/commits, or a team of maintainers. The single person model provides "ultimate" responsibility for that scope and a more predictable response to submissions, while a team distributes the workload and minimizes the impact of a single person becoming sick/distracted/trapped under bus/etc.
>> * Code modification voting: General process for Apache projects is to vote +1/0/-1. Question is, when do we use this? It probably isn't necessary for a 3 line commit.
>> * Responsiveness to patch submissions: One option to ensure prompt response to patch submissions would be to have some form of guidance similar to "maintainers will review and respond to patch submissions within 5 days" (pick a number). This isn't really enforceable as the community is neither employed by nor reports to a single entity, although repeated failures to meet the guideline could result in removal from the maintainer position.
>> * Patch testing: It would be great to have a test suite for a maintainer to easily confirm that a patch does not inadvertently affect functionality/logic outside the intended scope of the patch
>>
>> What have I left out? We referenced both the Linux (I can't find a good page describing their process?) and Drupal (http://drupal.org/contribute/core-maintainers) maintenance methods, but open to any others we can look at. Please give any thoughts on the subject, and definitely add any viewpoints/experiences/concepts that you may have.
>>
>> Thanks!
>>
>> John
>
> Thanks for starting the discussion John and bringing all of this back
> to the mailing list.
>
> I am a fan of the module maintainer method - but I think that it has
> some weaknesses - not necessarily unworkable, but things we should at
> least acknowledge if we think module maintainer is the way we begin to
> handle things. Namely:
>
> * Tends to result in SPOF - may need some mitigation strategies.
What might work is for smaller or less critical modules a single maintainer is OK, but PMC has ability to specify certain modules have multiple maintainers? That could provide flexibility to minimize overhead on some parts. Wouldn't want to make a module seem less important, though...
> * Need to ensure that it's not seen as authority or a place where
> decisions are made, but rather as a place of responsibility - with
> those responsibilities being the occasionally competing demands of
> getting changes in and maintaining quality.
> * This needs to be rotated regularly
I'm not sure about the regular rotation part - when I think of the large OSS projects, the maintainers have been in place for years...rotation requires getting somebody else up to speed?
> Of course, at best, these could only be informal rules - any committer
> could commit to anything in the repo.
>
> Anyone want to draft a proposal for us to try out?
I'm willing to take a stab, happy to work with others...
> I am also interested in some other workflow pieces. How do we do
> feature development (topic branches in git strike me as a good idea),
> how do we handle patches, etc.
Sorry, I left this off the initial email, wasn't sure if it was within scope of the discussion. Browsing through https://git-wip-us.apache.org/repos/asf, it looks like most projects branch either for feature dev or version branches...
Just found http://incubator.apache.org/isis/docbkx/html/guide/pt03.html while browsing - I can see borrowing from that. :) Voting on releases also makes sense.
John
Re: Maintainer/committer model for CloudStack
Posted by David Nalley <da...@gnsa.us>.
On Fri, May 4, 2012 at 12:24 AM, John Kinsella <jl...@stratosec.co> wrote:
> Guys - during the developer on-ramp this week, we held a group discussion around the topics of reviewing patch submissions, code maintainers, voting, and overall care and management of the official source tree. We wanted to continue the discussion on the developer list to look for the best way to set this up for CloudStack and I volunteered to kick off the discussion.
>
> For the overall scope of the discussion, I'm using "maintainer" to describe a person who has been given commit rights to trunk, and who reviews potential code modifications for inclusion into the CloudStack source. This is a separate responsibility from that of setting direction and priorities for the CS project. Just want to be clear. :)
>
> I'm going to list out some of the points and goals we discussed, but this probably isn't a complete list of things we should be considering:
>
> Goals:
> * Responsive maintainer team that nurtures involvement from the community by providing friendly, useful, efficient responses to code modification submissions
> * Responsibility vs authority - the goal is not to grant authority to maintain the codebase, but to culture responsibility and respect for the codebase and the community.
>
> Points to consider:
> * Maintainer scope: Is a maintainer responsible for certain parts of CS, or the overall codebase? As CS moves to a more modular architecture, maybe a maintainer focuses on a particular module? The concept of "super" maintainers was mentioned, a select group of people who have the ability to effect change across the entire code base. That one has such ability does not mean that it should be wielded often.
> * Single or multiple maintainers: Be there a given scope for a module, sub-project, or whatever, CS could adopt a model of a single "ultimate" maintainer who has to do all reviews/commits, or a team of maintainers. The single person model provides "ultimate" responsibility for that scope and a more predictable response to submissions, while a team distributes the workload and minimizes the impact of a single person becoming sick/distracted/trapped under bus/etc.
> * Code modification voting: General process for Apache projects is to vote +1/0/-1. Question is, when do we use this? It probably isn't necessary for a 3 line commit.
> * Responsiveness to patch submissions: One option to ensure prompt response to patch submissions would be to have some form of guidance similar to "maintainers will review and respond to patch submissions within 5 days" (pick a number). This isn't really enforceable as the community is neither employed by nor reports to a single entity, although repeated failures to meet the guideline could result in removal from the maintainer position.
> * Patch testing: It would be great to have a test suite for a maintainer to easily confirm that a patch does not inadvertently affect functionality/logic outside the intended scope of the patch
>
> What have I left out? We referenced both the Linux (I can't find a good page describing their process?) and Drupal (http://drupal.org/contribute/core-maintainers) maintenance methods, but open to any others we can look at. Please give any thoughts on the subject, and definitely add any viewpoints/experiences/concepts that you may have.
>
> Thanks!
>
> John
Thanks for starting the discussion John and bringing all of this back
to the mailing list.
I am a fan of the module maintainer method - but I think that it has
some weaknesses - not necessarily unworkable, but things we should at
least acknowledge if we think module maintainer is the way we begin to
handle things. Namely:
* Tends to result in SPOF - may need some mitigation strategies.
* Need to ensure that it's not seen as authority or a place where
decisions are made, but rather as a place of responsibility - with
those responsibilities being the occasionally competing demands of
getting changes in and maintaining quality.
* This needs to be rotated regularly
Of course, at best, these could only be informal rules - any committer
could commit to anything in the repo.
Anyone want to draft a proposal for us to try out?
I am also interested in some other workflow pieces. How do we do
feature development (topic branches in git strike me as a good idea),
how do we handle patches, etc.
--David
Re: Maintainer/committer model for CloudStack
Posted by Sheng Yang <sh...@yasker.org>.
On Fri, May 4, 2012 at 9:52 AM, Robert Schweikert <rj...@suse.com> wrote:
> On 05/04/2012 12:24 AM, John Kinsella wrote:
>>
>> Guys - during the developer on-ramp this week, we held a group discussion
>> around the topics of reviewing patch submissions, code maintainers, voting,
>> and overall care and management of the official source tree. We wanted to
>> continue the discussion on the developer list to look for the best way to
>> set this up for CloudStack and I volunteered to kick off the discussion.
>>
>> For the overall scope of the discussion, I'm using "maintainer" to
>> describe a person who has been given commit rights to trunk, and who reviews
>> potential code modifications for inclusion into the CloudStack source. This
>> is a separate responsibility from that of setting direction and priorities
>> for the CS project. Just want to be clear. :)
>>
>> I'm going to list out some of the points and goals we discussed, but this
>> probably isn't a complete list of things we should be considering:
>>
>> Goals:
>> * Responsive maintainer team that nurtures involvement from the community
>> by providing friendly, useful, efficient responses to code modification
>> submissions
>> * Responsibility vs authority - the goal is not to grant authority to
>> maintain the codebase, but to culture responsibility and respect for the
>> codebase and the community.
>>
>> Points to consider:
>> * Maintainer scope: Is a maintainer responsible for certain parts of CS,
>> or the overall codebase? As CS moves to a more modular architecture, maybe a
>> maintainer focuses on a particular module? The concept of "super"
>> maintainers was mentioned, a select group of people who have the ability to
>> effect change across the entire code base. That one has such ability does
>> not mean that it should be wielded often.
>
>
> I like the notion of maintainers on a smaller level. However, there have to
> be some people that maintain a reasonable overview of the complete codebase
> to make sure things move somewhat reasonably in the same direction.
+1. Here I like the typical hierarchy maintainer model. In CS probably
2 level is enough.
>
>
>> * Single or multiple maintainers: Be there a given scope for a module,
>> sub-project, or whatever, CS could adopt a model of a single "ultimate"
>> maintainer who has to do all reviews/commits, or a team of maintainers. The
>> single person model provides "ultimate" responsibility for that scope and a
>> more predictable response to submissions, while a team distributes the
>> workload and minimizes the impact of a single person becoming
>> sick/distracted/trapped under bus/etc.
>
>
> IMHO there should be multiple maintainers per sub-project/component/area of
> interest. If there is only one there is bound to be conflict at some point
> when a contributor and the maintainer cannot agree on some decisions. Having
> a couple of extra people chime in in such situations is always helpful.
IMO multiply maintainers may not be necessary. Because we're a
community, rather than really dictatorship country. People
would/should focus on the technically aspect, and if the contributor
and maintainer can not reach an agreement, community can be involved
in, as well as higher level maintainer. They're not necessary
maintainer. Single maintainer mode doesn't necessary means SPOF. When
the maintainer is on vacation, he/she or community can get a deputy
maintainer as well. At least we don't have a Linus Torvalds here. :)
Also, maintainer should be the expert on the one aspect, but it's not
necessary means maintainer would override the community.
>
>
>> * Code modification voting: General process for Apache projects is to
>> vote +1/0/-1. Question is, when do we use this? It probably isn't necessary
>> for a 3 line commit.
>
>
> One would hope that this should only be necessary for major changes, say a
> group of people works in a fork for a while and does some major
> re-architecting or whatever. When the branch comes back for merge it appears
> reasonable to vote. For general fixes and changes voting appears oevrkill to
> me.
Maybe a veto policy is more simple. "NACK", can be signed by the
members of community(not only maintainers). Most of time, if there are
no NACK, it should be fine. But if there are NACKs for the
patch/feature, it would need more discussion, unless 1. reach an
agreement, 2. or persuaded maintainer.
Of course, "ACK" can also be signed, if necessary. ACK can be used by
some expert(but not maintainers) in the fields.
>
>
>> * Responsiveness to patch submissions: One option to ensure prompt
>> response to patch submissions would be to have some form of guidance similar
>> to "maintainers will review and respond to patch submissions within 5 days"
>> (pick a number). This isn't really enforceable as the community is neither
>> employed by nor reports to a single entity, although repeated failures to
>> meet the guideline could result in removal from the maintainer position.
>
>
> Another option to "motivate" maintainers to get to reviews could be to
> automatically merge requests if they are X days past the "to be reviewed
> within" time period. Maintainers having an interest that their
> modules/components/areas of interest are not broken will not want
> automatically checked in code that they had no chance to review.
I don't think it's a good idea. If one maintainer didn't reply the
patch for weeks, there would be something wrong with the maintainer.
Contributor can bring everyone's attention on the mailing list, but
automatically merge the patch? That's seems too far for me.
>
>> * Patch testing: It would be great to have a test suite for a maintainer
>> to easily confirm that a patch does not inadvertently affect
>> functionality/logic outside the intended scope of the patch
>
>
> Yes, some kind of test suite comprised on unit tests and functional test
> would be great.
For certain part of code, maintainer can ask contributor to submit
test along with the patch. I know there are some limitation with our
unit test framework(e.g. test on some manager code), we need to work
on that as well.
>
>
>>
>> What have I left out? We referenced both the Linux (I can't find a good
>> page describing their process?) and Drupal
>> (http://drupal.org/contribute/core-maintainers) maintenance methods, but
>> open to any others we can look at. Please give any thoughts on the subject,
>> and definitely add any viewpoints/experiences/concepts that you may have.
>
And as a formal Linux kernel developer, I am very familiar with Linux
maintenance mode. I may able to write something about it later.
>
>
> In my experience people get discouraged quickly when proposed patches get no
> action for an extended period of time (more than a week). I think this has
> two reasons, contributors get the feeling that no one cares and after about
> a week or so when someone comes back and asks a question about the patch it
> is hard to come back and explain all the decisions along the way. Therefore,
> prompt action on pull/review requests is important.
>
> In addition to the more fine grained points listed here it is also important
> to set up some high level rules, such as "your patch breaks the build, it
> gets reverted, no ifs, whens and buts" if it is considered important to
> always have a non broken build, which IMHO it is.
+1.
--
regards
Yang, Sheng
>
> My $0.02
> Robert
>
>
> --
> Robert Schweikert MAY THE SOURCE BE WITH YOU
> SUSE-IBM Software Integration Center LINUX
> Tech Lead
> rjschwei@suse.com
> rschweik@ca.ibm.com
> 781-464-8147
Re: Maintainer/committer model for CloudStack
Posted by Robert Schweikert <rj...@suse.com>.
On 05/04/2012 12:24 AM, John Kinsella wrote:
> Guys - during the developer on-ramp this week, we held a group discussion around the topics of reviewing patch submissions, code maintainers, voting, and overall care and management of the official source tree. We wanted to continue the discussion on the developer list to look for the best way to set this up for CloudStack and I volunteered to kick off the discussion.
>
> For the overall scope of the discussion, I'm using "maintainer" to describe a person who has been given commit rights to trunk, and who reviews potential code modifications for inclusion into the CloudStack source. This is a separate responsibility from that of setting direction and priorities for the CS project. Just want to be clear. :)
>
> I'm going to list out some of the points and goals we discussed, but this probably isn't a complete list of things we should be considering:
>
> Goals:
> * Responsive maintainer team that nurtures involvement from the community by providing friendly, useful, efficient responses to code modification submissions
> * Responsibility vs authority - the goal is not to grant authority to maintain the codebase, but to culture responsibility and respect for the codebase and the community.
>
> Points to consider:
> * Maintainer scope: Is a maintainer responsible for certain parts of CS, or the overall codebase? As CS moves to a more modular architecture, maybe a maintainer focuses on a particular module? The concept of "super" maintainers was mentioned, a select group of people who have the ability to effect change across the entire code base. That one has such ability does not mean that it should be wielded often.
I like the notion of maintainers on a smaller level. However, there have
to be some people that maintain a reasonable overview of the complete
codebase to make sure things move somewhat reasonably in the same direction.
> * Single or multiple maintainers: Be there a given scope for a module, sub-project, or whatever, CS could adopt a model of a single "ultimate" maintainer who has to do all reviews/commits, or a team of maintainers. The single person model provides "ultimate" responsibility for that scope and a more predictable response to submissions, while a team distributes the workload and minimizes the impact of a single person becoming sick/distracted/trapped under bus/etc.
IMHO there should be multiple maintainers per sub-project/component/area
of interest. If there is only one there is bound to be conflict at some
point when a contributor and the maintainer cannot agree on some
decisions. Having a couple of extra people chime in in such situations
is always helpful.
> * Code modification voting: General process for Apache projects is to vote +1/0/-1. Question is, when do we use this? It probably isn't necessary for a 3 line commit.
One would hope that this should only be necessary for major changes, say
a group of people works in a fork for a while and does some major
re-architecting or whatever. When the branch comes back for merge it
appears reasonable to vote. For general fixes and changes voting appears
oevrkill to me.
> * Responsiveness to patch submissions: One option to ensure prompt response to patch submissions would be to have some form of guidance similar to "maintainers will review and respond to patch submissions within 5 days" (pick a number). This isn't really enforceable as the community is neither employed by nor reports to a single entity, although repeated failures to meet the guideline could result in removal from the maintainer position.
Another option to "motivate" maintainers to get to reviews could be to
automatically merge requests if they are X days past the "to be reviewed
within" time period. Maintainers having an interest that their
modules/components/areas of interest are not broken will not want
automatically checked in code that they had no chance to review.
> * Patch testing: It would be great to have a test suite for a maintainer to easily confirm that a patch does not inadvertently affect functionality/logic outside the intended scope of the patch
Yes, some kind of test suite comprised on unit tests and functional test
would be great.
>
> What have I left out? We referenced both the Linux (I can't find a good page describing their process?) and Drupal (http://drupal.org/contribute/core-maintainers) maintenance methods, but open to any others we can look at. Please give any thoughts on the subject, and definitely add any viewpoints/experiences/concepts that you may have.
In my experience people get discouraged quickly when proposed patches
get no action for an extended period of time (more than a week). I think
this has two reasons, contributors get the feeling that no one cares and
after about a week or so when someone comes back and asks a question
about the patch it is hard to come back and explain all the decisions
along the way. Therefore, prompt action on pull/review requests is
important.
In addition to the more fine grained points listed here it is also
important to set up some high level rules, such as "your patch breaks
the build, it gets reverted, no ifs, whens and buts" if it is considered
important to always have a non broken build, which IMHO it is.
My $0.02
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147