I was in favor of blocking 4.1 due to the upgrade issue, but I actually changed
my mind.
We should stick with a time based philosophy and release on-time, then work on
fixes in bug fix releases.
Pausing merges of new features seems wrong to me, instead we should keep
releasing to make sure
Hi.
+1 for making effort to keep 4.1 maintained.
As far as I know, there're many people waiting 4.1 release.
IMHO, blocking merges in master is another topic.
# I assume you're tired watching 4.1
As the master is getting dirty, inconsistent and
looks like unmaintained, it may seem to be
To answer the doc part of John's question, I believe the documentation
changes required would be small. Just update the URL in the system VM
download step in the installation guide, and possibly add a restart system
VMs and virtual routers step to the upgrade instructions, if needed.
Jessica t.
On Wed, May 22, 2013, at 04:53 AM, Hiroaki KAWAI wrote:
+1 for making effort to keep 4.1 maintained.
As far as I know, there're many people waiting 4.1 release.
There are many people waiting for a 4.1 release *they can use*.
There's nothing to stop end users from grabbing the 4.1 tree in its
Prasanna,
It seems to me our largest concern is that the impending 4.2 code freeze will
create a priority conflict between stabilizing 4.1 and completing 4.2 features
(including reviews). Would it be acceptable to push back the 4.2 until say two
weeks after the first 4.1 RC ships? With this
On Tue, May 21, 2013 at 12:34:45AM +, Chiradeep Vittal wrote:
I don't see limited interest. It seems that bugs are trickling in every
day and they are being taken up as they come in. Is there any blocker
without any action for more than a few days? The only one I can see
CLOUDSTACK-2463.
On Tue, May 21, 2013 at 4:18 PM, Chip Childers
chip.child...@sungard.com wrote:
On Tue, May 21, 2013 at 12:34:45AM +, Chiradeep Vittal wrote:
I don't see limited interest. It seems that bugs are trickling in every
day and they are being taken up as they come in. Is there any blocker
But the longer we hold the window open for folks to raise defects, the
longer it will take to release. Why can't we enforce our own timelines and
say this is it. Any release will have blockers for a subset of users. It
seems to me that we are inefficient in estimating the harm from a
'blocker'
Chiradeep,
This defect affects 100% of users that use system VMs which I believe
is all of them. It also appears that we have a fix for this problem
that needs to be pulled back from 4.2 and tested. What is involved
with testing it?
Personally, I would be please if we found more blockers
All,
I would prefer a better release an wait for it then to have to deal with
multiple updates because of issues, just my $.02..
Sean
On May 21, 2013, at 7:00 PM, Chiradeep Vittal chiradeep.vit...@citrix.com
wrote:
But the longer we hold the window open for folks to raise defects, the
I'm not arguing the value of blockers. Sure they are valuable. But our
estimate of the harm (IMO) is totally out of proportion. Take the time
sync issue. This has been there since 2.2.0. Are we saying that the
thousands of production Cloudstack clouds are well and truly borked and
cannot function?
There's ALWAYS known issues in every release. The release manager,
developers, support (in this case developers), product managers (in this
case community at large) and customers (users) at some point put the value
of getting new code and new features ahead of fixing ALL known issues.
I suggest
All,
Can someone please answer the following questions:
1. Besides testing, what work needs to be done back port the 4.2
system VMs to 4.1 (e.g. docs, posting images for download, etc)?
2. What is involved to test/verify the operation of 4.2 system VMs
on 4.1? What is labor/time estimate?
I completely agree but when does features an enhancements come before QA an
overall stability of a product? I guess it all depends on customers base.
Sean
On May 21, 2013, at 7:28 PM, Chiradeep Vittal chiradeep.vit...@citrix.com
wrote:
There's ALWAYS known issues in every release. The
John,
Usually testing of templates require regression testing which usually take ~2
week ( need to run core regression on them ). It is usually preferred to test
templates early on in release given the risk and also it would get enough
coverage by all the testing that happens during release
John,
I would not say as far as that but it does require some baking time and of
course resources.
Below are the basic tests that can certify template functionality however as
mentioned earlier regression need to be done as templates impact broader
feature set. Below tests are done to
-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com]
Sent: Monday, May 20, 2013 1:35 PM
To: dev@cloudstack.apache.org
Subject: [DISCUSS] Should we pause merges into master until 4.1 is out the
door?
All,
I can't help but notice that we continue to have
-Original Message-
From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
Sent: Monday, May 20, 2013 5:35 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Should we pause merges into master until 4.1 is out
the door?
I don't see limited interest. It seems that bugs
On Mon, May 20, 2013 at 04:34:58PM -0400, Chip Childers wrote:
All,
I can't help but notice that we continue to have features being developed and
proposed / merged into master while I struggle to get opinions / help on
4.1. I doubt that we (as a community) want to abandon 4.1, but I can't
19 matches
Mail list logo
