incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Kinsella <...@stratosec.co>
Subject Re: Maintainer/committer model for CloudStack
Date Wed, 16 May 2012 18:33:44 GMT
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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message