incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Schweikert <rjsch...@suse.com>
Subject Re: Maintainer/committer model for CloudStack
Date Wed, 16 May 2012 12:33:04 GMT
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

Mime
View raw message