I'm glad you guys (Paul and Rafael) agree with me. We should cut a branch once the first RC is built. Then we should only allow blockers in to fix RC issues.
This should speed up our releases in the future. > On Jun 27, 2017, at 10:14 AM, Rafael Weingärtner > <rafaelweingart...@gmail.com> wrote: > > +1 to what Paul said. > IMHO, as soon as we start a release candidate to close a version, all > merges should stop (period); the only exceptions should be PRs that address > specific problems in the RC. > I always thought that we had a protocol for that [1]; maybe for this > version, we have not followed it? > > [1] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen > > On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus <paul.an...@shapeblue.com> > wrote: > >> Hi All, >> >> From my view point 'we' have been the architects of our own downfall. Once >> a code freeze is in place NO new features, NO enhancements should be going >> in. Once we're at an RC stage, NO new bug fixes other that for the blockers >> should be going in. that way the release gets out, and the next one can get >> going. If 4.10 had gone out in a timely fashion, then we'd probably be on >> 4.11 if not 4.12 by now, with all the new features AND all the new fixes in. >> >> People sliding new changes/bug fixes/enhancements in are not making the >> product better, they're stopping progress. As we can clearly see here. >> >> >> Kind regards, >> >> Paul Angus >> >> paul.an...@shapeblue.com >> www.shapeblue.com >> 53 Chandos Place, Covent Garden, London WC2N 4HSUK >> @shapeblue >> >> >> >> >> -----Original Message----- >> From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com] >> Sent: 27 June 2017 01:25 >> To: dev@cloudstack.apache.org >> Cc: Wido den Hollander <w...@widodh.nl> >> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3 >> >> I tend to agree with you here, Daan. I know the downside we’ve discussed >> in the past is that overall community participation in the RC process has >> dropped off when such a new branch is created (since the community as a >> whole tends to focus more on the new branch rather than on testing the RC >> and releasing it). >> >> I believe we should do the following: As we approach the first RC, we need >> to limit the number of PRs going into the branch (in order to stabilize >> it). If we had a super duper array of automated regression tests that ran >> against the code, then we might be able to avoid this, but our automated >> test suite is not extensive enough for us to do so. >> >> As we approach the first RC, only blockers and trivial (ex. text changes) >> PRs should be permitted in. Once we cut the first RC, create a new branch >> for ongoing dev work. In between RCs, we can only allow in code related to >> blocker PRs (or trivial text changes, as discussed before). >> >> What do people think? >> >> On 6/13/17, 4:56 AM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: >> >> this is why i say we should branch on first RC, fix in release branch >> only and merge forward >> >> On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens < >> williamstev...@gmail.com> wrote: >>> I know it is hard to justify not merging PRs that seem ready but are >> not >>> blockers in an RC, but it is a vicious circle which ultimately >> results in a >>> longer RC process. >>> >>> It is something i struggled with as a release manager as well. >>> >>> On Jun 13, 2017 1:56 AM, "Rajani Karuturi" <raj...@apache.org> >> wrote: >>> >>> Thanks Mike, >>> >>> Will hold off next RC until we hear an update from you. >>> >>> Regarding merging non-blockers, unfortunately, its a side-effect >>> of taking more than three months in the RC phase :( >>> >>> Thanks, >>> >>> ~ Rajani >>> >>> http://cloudplatform.accelerite.com/ >>> >>> On June 13, 2017 at 10:10 AM, Tutkowski, Mike >>> (mike.tutkow...@netapp.com) wrote: >>> >>> Hi everyone, >>> >>> I had a little time this evening and re-ran some VMware-related >>> tests around managed storage. I noticed a problem that I’d like >>> to investigate before we spin up the next RC. Let’s hold off on >>> the next RC until I can find out more (I should know more within >>> 24 hours). >>> >>> Thanks! >>> Mike >>> >>> On 6/12/17, 2:40 AM, "Wido den Hollander" <w...@widodh.nl> >>> wrote: >>> >>>> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike" >>> <mike.tutkow...@netapp.com>: >>>> >>>> >>>> Hi, >>>> >>>> I opened a PR against the most recent RC: >>> https://github.com/apache/cloudstack/pull/2141 >>>> >>>> I ran all managed-storage regression tests against it and they >>> pass (as noted in detail in the PR). >>>> >>>> If someone wants to take this code and create a new RC from >>> it, I’m +1 on the new RC as long as this is the only commit added >>> to it since the current RC. >>> >>> Thanks Mike! >>> >>> If this PR is good we should probably merge it asap and go for >>> RC5. >>> >>> 4.10 should really be released by now. >>> >>> Wido >>> >>>> >>>> Thanks! >>>> Mike >>>> >>>> On 6/9/17, 7:43 PM, "Tutkowski, Mike" >>> <mike.tutkow...@netapp.com> wrote: >>>> >>>> Hi everyone, >>>> >>>> I found a critical issue that was introduced into this RC >>> since the most recent RC, so I am -1 on this RC. >>>> >>>> The fix for this ticket breaks the support for storing volume >>> snapshots on primary storage (which is a feature managed storage >>> can support): >>>> >>>> https://issues.apache.org/jira/browse/CLOUDSTACK-9685 >>>> >>>> Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e >>>> >>>> At a high level, what it does is remove a row from the >>> cloud.snapshot_store_ref table when a volume is deleted that has >>> one or more volume snapshots. >>>> >>>> This is fine for non-managed (traditional) storage; however, >>> managed storage can store volume snapshots on primary storage, so >>> removing this row breaks that functionality. >>>> >>>> I can fix the problem that this commit introduced by looking >>> at the primary storage that supports the volume snapshot and >>> checking the following: 1) Is this managed storage? 2) If yes, is >>> the snapshot in question stored on that primary storage? >>>> >>>> The problem is I will be out of the office for a couple weeks >>> and will not be able to address this until I return. >>>> >>>> We could revert the commit, but I still will not have time to >>> run the managed-storage regression test suite until I return. >>>> >>>> On a side note, it looks like this commit was introduced since >>> the most recent RC. I would argue that it was not a blocker and >>> should not have been placed into the new RC. We (as a community) >>> tend to have a lot of code go in between RCs and that just >>> increases the chances of introducing critical issues and thus >>> delaying the release. We’ve gotten better at this over the years, >>> but we should focus more on only allowing the entry of new code >>> into a follow-on RC that is critical (or so trivial as to not at >>> all be likely to introduce any problems…like fixing an error >>> message). >>>> >>>> Thanks for your efforts on this, everyone! >>>> Mike >>>> >>>> On 6/9/17, 8:52 AM, "Tutkowski, Mike" >>> <mike.tutkow...@netapp.com> wrote: >>>> >>>> Hi Rajani, >>>> >>>> I will see if I can get all of my managed-storage testing >>> (both automated and manual) done today. If not, we’ll need to see >>> if someone else can complete it before we OK this RC as I won’t >>> be back in the office for a couple weeks. I’ll report back later >>> today. >>>> >>>> Thanks, >>>> Mike >>>> >>>> On 6/9/17, 2:34 AM, "Rajani Karuturi" <raj...@apache.org> >>> wrote: >>>> >>>> Yup. thats right. I dont know how it happened but, it created >>>> from the previous RC commit. The script is supposed to do a >>> git >>>> pull. I didn't notice any failures. Not sure what went wrong. >>>> >>>> Thanks for finding it mike. I am creating RC4 now and >>> cancelling >>>> this. >>>> >>>> ~ Rajani >>>> >>>> http://cloudplatform.accelerite.com/ >>>> >>>> On June 9, 2017 at 12:07 PM, Tutkowski, Mike >>>> (mike.tutkow...@netapp.com) wrote: >>>> >>>> Hi Rajani, >>>> >>>> I don’t see the following PR in this RC: >>>> >>>> https://github.com/apache/cloudstack/pull/2098 >>>> >>>> I ran all of my managed-storage regression tests. They all >>>> passed with the exception of the one that led to PR 2098. >>>> >>>> As I examine the RC in a bit more detail, it sits on top of >>>> ed2f573, but I think it should sit on top of ed376fc. >>>> >>>> As a result, I am -1 on the RC. >>>> >>>> It takes me about a day to run all of the managed-storage >>>> regression tests and I am out of the office for the next >>> couple >>>> weeks, so I’d really like to avoid another RC until I’m back >>> and >>>> able to test the next RC. >>>> >>>> Thanks! >>>> Mike >>>> >>>> On 6/7/17, 4:36 AM, "Rajani Karuturi" <raj...@apache.org> >>> wrote: >>>> >>>> Hi All, >>>> >>>> I've created 4.10.0.0 release with the following artifacts up >>>> for a vote: >>>> >>>> Git Branch and Commit SH: >>>> >>> https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h= >>> a55738a31d0073f2925c6fb84bf7a6bb32f4ca27 >>>> Commit:a55738a31d0073f2925c6fb84bf7a6bb32f4ca27 >>>> Branch: 4.10.0.0-RC20170607T1407 >>>> >>>> Source release (checksums and signatures are available at the >>>> same >>>> location): >>>> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/ >>>> >>>> SystemVm Templates: >>>> http://download.cloudstack.org/systemvm/4.10/RC3/ >>>> >>>> PGP release keys (signed using CBB44821): >>>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS >>>> >>>> Vote will be open for 72 hours. >>>> >>>> For sanity in tallying the vote, can PMC members please be >>> sure >>>> to indicate >>>> "(binding)" with their vote? >>>> >>>> [ ] +1 approve >>>> [ ] +0 no opinion >>>> [ ] -1 disapprove (and reason why) >>>> >>>> Thanks, >>>> ~Rajani >>>> http://cloudplatform.accelerite.com/ >>>> >>>> >>>> >>>> >>>> >> >> >> >> -- >> Daan >> >> >> > > > -- > Rafael Weingärtner
