thanks guys, To bad I couldn't stay for this but I'll take some time to send you my nagging on this soon ;) I hope I can afford to spend a lot of time on generic quality issues on Leaseweb's accord. We will be discussing this on Monday.
On Fri, Oct 9, 2015 at 6:07 PM, Pierre-Luc Dion <pdion...@apache.org> wrote: > Here is a quick meeting note of a round table related to new QA > infrastructure > and tests of 4.6 release. > > State of the QA infrastructure donated by Citrix > ================================================ > > ~ 10 servers in viginial > > Questions: > 1. how to use it > 2. how do we control it > > nested hypervisor is slow > > BVT cycle time 2 to 3 hours > > - Citrix QA to provide solution to rebuild hypervisor after each testrun. > - hardware installation perform and ready to be provisionned. > - Possiblity to run QA job on vendor site via jenkins slaves > - Need to move jenkins jobs running on j.bac.o into jenkins.apache.org > - Need a box to build systemvm template on server having Virtual-box > > > ACS 4.6 > ======= > > - 4 blockers left > - Please comment what you did to test a PR with your LGTM. > - Most recent PR does not include tests or does not point which tests PR's > are > solving > - Look like the new PR model solve the past issue where master build was > broken > most of the time. > - Travis does not test all from the simulator, we will enable all test, > this > will slow down travis jobs but will help on quality. > - Need QA volunteers to test 4.6 so we can push for an RC soon. > - update the README.md about how to contribute the CloudStack to PR. > - Still need to build a release-note for 4.6 > - [NEED VOTE] for PR that will not have response to comment will be close > after > X days, submitter can still reopen the PR. > - Need more unit test. We have a hard need for unittest because they help > trap > small function issues that can cause serious damaged to running VM and > speedup > guarantee quality of releases. > - [VOTE or DISCUSS needed] new features should be ported via multiple PRs > into > a community would see feature evolution feature branch. When a feature is > ready then a merge would be requested. but fork should be prefer as it's > also > to do collaborative coding on github fork. > - lot of discussion around unit tests and marvin tests. > -- Daan
