+1 to create a new RC with the fix. Also pl review if there are any additional fixes that need to go in. Before the new RC need to resolve the following defects in my opinion
https://issues.apache.org/jira/browse/CLOUDSTACK-285 - Kelven ?? https://issues.apache.org/jira/browse/CLOUDSTACK-294 - this is resolved - just need to put it in resolved status https://issues.apache.org/jira/browse/CLOUDSTACK-318 - This has been checked and common scenario. Need to understand use case as this is not reproducible https://issues.apache.org/jira/browse/CLOUDSTACK-324 - QA is checking this one https://issues.apache.org/jira/browse/CLOUDSTACK-325 - there is a workaround for this one - But see if you can fix it before you cut second RC QA will validate next RC for sanity validation and will cast vote based on validation. However you can go ahead with outlined plan below. Thanks /Sudha -----Original Message----- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Thursday, October 11, 2012 7:45 PM To: <cloudstack-dev@incubator.apache.org> Subject: Re: [VOTE] Apache Cloudstack 4.0.0-incubating Release, first round On Oct 11, 2012, at 10:04 PM, Edison Su <edison...@citrix.com> wrote: > Both of these issues we found today are not blocker and the fixes are trivial. > We don't need another round test from QA team: the fix for bug CloudStack-316 > is agreed by Wido, Marcus and I, and tested by Wido, another bug fixes are > related to legal. Agreed. If we abort, we can immediately cut another release candidate and start another vote. No need for the test engineers in the community to due a full round of testing prior to seeing a new vote. I would, however, love any future vote to include test engineers personally voting based on testing the official RC artifacts! > Seems recasting another round voting is inevitable? > I'm going to leave this thread open until the morning to gather more opinions and comments. However, I think you are right. In all likelihood, I'll abort tomorrow morning and create a new RC and vote thread. > Sent from my iPhone > > On Oct 11, 2012, at 5:47 PM, "Simon Weller" <swel...@ena.com> wrote: > >> >> >> <On Thu, Oct 11, 2012 at 7:56 PM, Wido den Hollander <w...@widodh.nl> wrote: >>> >>> >>> On 10/11/2012 03:21 AM, Chip Childers (ASF) wrote: >>>> >>>> Hi All, >>>> >>>> I would like to call a vote for Apache CloudStack (Incubating) >>>> Release 4.0.0-incubating. >>>> >>>> Instructions for Validating and Testing the artifacts can be found here: >>>> >>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4 >>>> .0+test+procedure >>>> >>>> We encourage the whole community to download and test these release >>>> artifacts so that any critical issues can be resolved before the >>>> release is made. Everyone is free to vote on this release, so >>>> please give it a shot! >>> >>> >>> Sorry for stopping the +1 spree, but I'm going to vote -1. >>> >>> While testing the artifact I ran into CLOUDSTACK-316 (which I created). >>> >>> QA (nofi) only tested with cloudbr0 in their setup and never tested >>> usage with other traffic labels. >>> >>> After talking with Edison and Marcus we came up with commit >>> 513b680d96d07fd44479995ac5eb6358725c9421 which resolves it. >>> >>> The problem in my setup was that adding the host would fail and >>> you'd have to figure out what was going wrong. >>> >>> I understood what was going wrong, but this would/could scare a new >>> user away since a very simple use-case didn't work during the wizard. >>> >>> So my vote is -1 on this artifact. >>> >>> Wido >>> >>> Wido, >>> >>> Thanks for the detailed testing. >>> >>> IMO, I believe we would be best served aborting round 1 and >>> regenerating a new release artifact with the fix for your issue. I >>> would also include the fixes for at least CLOUDSTACK-314 (Citrix >>> license header remains in >>> test/integration/component/test_allocation_states.py) and >>> CLOUDSTACK-302 (New Features Are Added to ReleaseNotes). Both of >>> these are low risk changes, but important documentation and legal >>> issues. >>> >>> I'm not going to abort the vote immediately, but I would like to get >>> opinions from other community members on this topic. >>> >>> -chip >> >> This is a good catch. We have always used cloudbr0, so we didn't test this >> in our lab either. This definitely needs to be addressed as it's going to >> cause lots of pain for new KVM users. >> >> I'm changing my vote to -1. >> >> - Si >> >> <snip> >
