On 05/23/2013 06:35 PM, Chip Childers wrote:
On Wed, May 22, 2013 at 09:25:10PM +0000, Edison Su wrote:


-----Original Message-----
From: Chip Childers [mailto:chip.child...@sungard.com]
Sent: Wednesday, May 22, 2013 1:26 PM
To: dev@cloudstack.apache.org
Subject: Re: [MERGE]object_store branch into master

On Wed, May 22, 2013 at 08:15:41PM +0000, Animesh Chaturvedi wrote:


-----Original Message-----
From: Chip Childers [mailto:chip.child...@sungard.com]
Sent: Wednesday, May 22, 2013 12:08 PM
To: dev@cloudstack.apache.org
Subject: Re: [MERGE]object_store branch into master

On Wed, May 22, 2013 at 07:00:51PM +0000, Animesh Chaturvedi wrote:


-----Original Message-----
From: John Burwell [mailto:jburw...@basho.com]
Sent: Tuesday, May 21, 2013 8:51 AM
To: dev@cloudstack.apache.org
Subject: Re: [MERGE]object_store branch into master

Edison,

Thanks, I will start going through it today.  Based on other
$dayjob responsibilities, it may take me a couple of days.

Thanks,
-John
[Animesh>] John we are just a few days away  from 4.2 feature
freeze, can
you provide your comments by Friday 5/24.   I would like all feature
threads
to be resolved sooner so that we don't have last minute rush.

I'm just going to comment on this, but not take it much further...
this type of change is an "architectural" change.  We had previously
discussed (on several
threads) that the appropriate time for this sort of thing to hit
master was
*early* in the release cycle.  Any reason that that consensus
doesn't apply here?
[Animesh>] Yes it is an architectural change and discussion on this started a
few weeks back already, Min and Edison wanted to get it in sooner by  4/30
but it took longer than anticipated in  preparing for merge and testing on
feature branch.



You're not following me I think.  See this thread on the Javelin merge:

http://markmail.org/message/e6peml5ddkqa6jp4

We have discussed that our preference is for architectural changes to hit
master shortly after a feature branch is cut.  Why are we not doing that here?

This kind of refactor takes time, a lot of time. I think I worked on the merge 
of primary storage refactor into master and bug fixes during 
March(http://comments.gmane.org/gmane.comp.apache.cloudstack.devel/14469), then 
started to work on the secondary storage refactor in 
April(http://markmail.org/message/cspb6xweeupfvpit). Min and I finished the 
coding at end of April, then tested for two weeks, send out the merge request 
at middle of May.
With the refactor, the  storage code will be much cleaner, and the performance 
of S3 will be improved, and integration with other storage vendor will be much 
easier, and the quality is ok(33 bugs fired, only 5 left: 
https://issues.apache.org/jira/issues/?jql=text%20~%20%22Object_Store_Refactor%22).
 Anyway, it's up to the community to decide, merge it or not, we already tried 
our best to get it done ASAP.



I'm absolutely not questioning the time and effort here.  I know that
you have been working hard, and that testing is happening!

I'm only asking if we, as a community, want to follow the practice of
bringing changes like this in early or late in a cycle.  I thought we
had agreed on doing it early.


So I tried reviewing the code, but I have to say that it is a lot of code. Reviewing such a large piece of code isn't easy.

Now, let me be honest, I'd love to see this in 4.2 since it would make the Ceph integration a lot better. We can get rid of NFS as Secondary Storage and use Ceph as the only storage for CS.

Yes, it might need some work after this branch has been merged, but I do agree that it's a lot of work to maintain a branch next to master. Even with smaller fixes you have to do a lot to keep up.

Imho a feature freeze is a feature freeze. It's set for May 31st and afterwards we start ironing the bugs out, but no new merges from other branches.

We will need the full support from Edison and Co to help iron out these bugs. Maybe something will be broken after the merge and that should be fixed asap then.

Again, my opinion in this is a bit coloured, but I think this will be a great addition to CloudStack, it would make 4.2 a killer release.

Wido

Reply via email to