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

Reply via email to