Guiding principles

The work in this improvement effort is guided by two principles

  1. Hospitality; what we are doing should be inviting to new contributors and present day commiter and contributors alike. People should enjoy submitting patches to the project and not be inhibited by the process.
  2. Quality; Contributed code should be chacked in all possible ways on correctness, both from syntactic and semantic perspective.

 

Guidelines on operating this collaborative wiki

  • This is really a scratch pad for now, please add your raw comments  above the formatted content line
  • You can add questions as comments to provide context

Goals

Development workflow 

  1. Continuous integration and test automation
    • Different individuals and organization can contribute  
    • Testing and automation
      • The community consists of individuals contributing to the project, a replicable testing infra which scales from laptops to large clusters is needed. (Example KVM based: https://github.com/bhaisaab/peppercorn)
      • Use CloudStack to build/run//test CloudStack in a nested environment (PoC Xen/KVM on KVM based ACS cluster 2 baremetal servers, 32GB RAM, 1Tb storage - http://yadav.website:8080/client)
      • Have a minimal HVM Linux testing template for testing user VMs and features such as reset password/ssh keys etc. (https://issues.apache.org/jira/browse/CLOUDSTACK-8038)
      • Improvement in Marvin or a new library (such as Edison was working on a  new test library)
      • Fix integration tests so they can run on an nested-virtualized environment described above, add more integration tests to increase coverage
      • Smoke Tests and Integration tests
        • Improve TravisCI, which can run smoke tests in about 20-30 mins per check-in: https://travis-ci.org/apache/cloudstack/builds and every person can have their own TravisCI running against their Github fork
        • Add more infra on Jenkins so it can do both smoke tests and integration tests
  2. Gating of commits
    1. how should the gate be guarded
    2. what are the conditions to guard for/against
  3. Overall commit workflow
    • Where is the bug fix made first?
      • Approach 1: All bug fixes go in master first and pulled into specific branches
      • Approach 2: Bug fix in release branch and then in master
    • Gerrit
      • Pros
      • Cons
        • Who will review a pending request (same issue as using Github or ReviewBoard)
        • Discuss - adopt a maintainer model where a maintain is supposed to review all review requests or contributions related to a component (similar to Linux)
        • Hard to implement for a community of individual contributors
    • Travis
      • Pros
      • Cons
        • It will not scale for one account (https://travis-ci.org/apache/cloudstack) due to several checkin being evaluated on all branches and every single commit 
        • TravisCI is scalable for the community because everyone can have their own TravisCI account, link to their Github fork and run several concurrent smoke tests with simulator in about 20 mins time.
    • Git hub 
      • Simple to use, everyone has probably already used it or know it
    • Code review
      • Simple workflow
      • Who will sign up for review?
    • Automation and testing 
    •  
    • Non committer workflow v/s Committer workflow
    1. Should this be consistent?
    2. Pull request v/s Reviewboard 
    • Commit Workflow ideas
      • Merge branches to master often, example 4.5 getting merged on master often
      • Favour branch merges over cherry-picks
      • A bugfix needs to be backported to all affected older branches
      • All feature work and bugfix work can be done in separate branches which need not be gated
      • Accept new feature if they have a good spec and 80+% test coverage

 

Put refined and formatted content below this line

 

Support  

As per our Releases guideline we support N-1 release for critical and security fixes. See the section Releases#SupportLifetimeofaRelease for more details Where  N is the current release being worked on and has not been officially released. If issues are found in prior release and they affect supported releases the fix should be ported in those release. It should certainly go in N and master.

If someone wants to provide fixes for prior unsupported releases they can do so on their own choosing but they cannot expect back porting of fixes by community It is expected that they will monitor critical fixes in supported branches including security fixes. They are also expected to maintain the forward fixes into supported releases and maintain upgrade path.

Release Management 

  • JIRA
    • Lots of open unassigned issues
    • Auto assignment and rotation of responsibility ever major release 
      • Auto assignment is obligation for assignee and as such will not be endorsed by community and gives the impression of control
      • However we can define fine grained component / sub-component and volunteer maintainer list. People can add or remove their name as maintainer for specific components anytime.
      • We can set up filter for open issues and new issues which the maintainers can subscribe to.
    • Prune out older issues, if no one has picked up in a year. 
    • Components Deprecation Policy
      • If a component is not actively maintained and the community is not able to support it. It will be called out to be deprecated from the next active release and the notification sent to dev and user list.
        • Deprecation
          • Disable from UI and API
          • Open Item: When can we remove the deprecated component from source tree?
 

 

 

 

 

  • No labels

1 Comment

  1. Daan

    security issue: let's look into OWASP Dependency Check our code in one of our builds.