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
