> -----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. > > 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
