If all of our testing were completely in an automated fashion, then I would
agree that the 72-hour window is sufficient. However, we don’t have that kind
of automated coverage and people aren’t always able to immediately begin
testing things out like migrating from their version of CloudStack to the new
one. That being the case, 72 hours does seem (at least for where we are now as
a project in terms of automated testing coverage) a bit short.
On 1/17/18, 7:52 AM, "Daan Hoogland" <daan.hoogl...@shapeblue.com> wrote:
The 72 hours is to make sure all stakeholders had a chance to glance.
Testing is supposed to have happened before. We have a culture of testing only
after RC-cut which is part of the problem. The long duration of a single test
run takes, is another part. And finally, in this case there is the new mindblow
called meltdown. I think in general we should try to keep the 72 hours but for
this release it is not realistic.
On 17/01/2018, 15:48, "Rene Moser" <m...@renemoser.net> wrote:
On 01/17/2018 03:34 PM, Daan Hoogland wrote:
> People, People,
>
> a lot of us are busy with meltdown fixes and a full component test
takes about the 72 hours that we have for our voting, I propose to extend the
vote period until at least Monday.
+1
I wonder where this 72 hours windows come from... Is it just be or,
based on the amount of changes and "things" to test, I would like to
expect a window in the size of 7-14 days ...?
René
daan.hoogl...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
