On May 24, 2013, at 5:50 PM, Animesh Chaturvedi <animesh.chaturv...@citrix.com> wrote:
> > >> -----Original Message----- >> From: Chip Childers [mailto:chip.child...@sungard.com] >> Sent: Friday, May 24, 2013 2:42 PM >> To: <dev@cloudstack.apache.org> >> Subject: Re: [MERGE]object_store branch into master >> >> 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). > [Animesh>] It may seems so now but the plan was to finish this for 4.2 What plan? Isn't the community review and technical quality of this more important anyway? >> >>> >>>> >>>> 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 >
