On May 24, 2013, at 5:25 PM, Animesh Chaturvedi <animesh.chaturv...@citrix.com> wrote:
> > >> -----Original Message----- >> From: Chip Childers [mailto:chip.child...@sungard.com] >> Sent: Friday, May 24, 2013 1:18 PM >> To: dev@cloudstack.apache.org >> Subject: Re: [MERGE]object_store branch into master >> >> On Thu, May 23, 2013 at 05:50:49PM +0000, Animesh Chaturvedi wrote: >>> [Animesh>] IMHO the goal behind bringing architectural changes early >> in release is to ensure stability and proper review and that makes >> sense. In this case the goals are being addressed with testing on >> feature branch and BVT. Min, Edison did a lot of unit testing for 2 >> weeks before sending merge request. Sangeetha / Rayees has filed a >> number of issues that are being addressed and the review request was put >> in last week much ahead of the freeze date. >> >> No, the review aspect has not been addressed well for this. >> The goal of this community should *always* be to ensure that our >> releases are a product of the whole community. This level of change is >> not something that is easily reviewed by volunteer community members in >> such a short time frame. > [Animesh>] I understand review of big change like this takes longer but it > cannot be unbounded. If the code stays waiting to merge longer and the master > moves in meantime, it becomes stale and requires lot more effort to revise it > again and will be frustrating to contributors. How long does community need > to review the changes? > >> >> Not much discussion on the specific decisions happened on the list (yes >> some did), so the merge into master process we use is really the >> inflection point where a sub-set of the community says "hey, look at >> this stuff we've been working on... give feedback and let us know if >> there is agreement to bring it into the main code line". This should be >> a positive period to show off good work, and to collaborate in areas >> where there are still problems. >> >> My question has still not been answered: Are we explicitly saying that, >> as a community, we feel that significant structural changes to the code >> should be brought in at the very end of a release "merge" window? I'm >> -1 on that approach in general terms, and have Javelin as the past >> example of this not being a good practice for our project. > [Animesh>] Javelin was an important lesson to learn from and that's why this > time there was extensive QA and dev testing done on feature branch prior to > sending out MERGE request. As for your question IMO if the community agrees > that the architecture changes are stable, reviewed and valuable it could be > brought in towards the end of cycle. If the criterions are not met than > certainly it should not be allowed. Pragmatically speaking with architectural > changes like this it is hard to time them perfectly to arrive right at the > beginning of the next release cycle. Isn't this one timed pretty darn well for that approach? We branch 4.2 in 1 week. Sounds like an easy answer to merge after that (assuming all of the issues are being addressed). > >> >> Don't confuse what I'm saying though. I respect what is being >> attempted. I respect the work that went into it. Neither of these >> things are in question. >> >> -chip >
