Page History

...

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
    • Cons : This will slow us down and will not scale Only supported releases get critical and security fixes. Check Releases#SupportLifetimeofaRelease. 
  • 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

...