You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

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

Support  

As per our Releases guideline we support N-1 release for critical and security fixes. See the section Releases#SupportLifetimeofaRelease for more details

 

 

Release Management 

 

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
    • JIRA
      • Lots of open unassigned issues
      • Auto assignment and rotation of responsibility ever major release 
  2. Gating of commits
  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

 

 What questions are we ready to take up now?
  1. What is broken with committer workflow? 
  What questions are we ready to push out and accept status-quo?

 

2014-12-17 - pre meeting
  1. What is broken with committer workflow? 
    1. Master branch is most likely broken and cannot be build. As contributor, it is the default branch to use of building a patch, new feature, or customize the code.
    2. Patch, cannot be merge between release branch and master most of the time, it is difficult to keep track of changes as they are 'cherry-pick'
  2. What questions are we ready to push out and accept status-quo?
    1. Concept of merge request where release manager would be responsible of Merging?
    2. Jenkins is now sleeping, let's use it to use the simulator and any automated tests against release branch and maybe to_merge branches?

I think with what we currently have (jenkins hardware, merge request) we should be able to improve process quickly without imposing gated commit as the first step.  Let's discuss ...

 

 

 

 

 

 

  • No labels