+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
