> -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Friday, May 24, 2013 2:54 PM > To: <dev@cloudstack.apache.org> > Subject: Re: [MERGE]object_store branch into master > > 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? > [Animesh>] Plan means targeted for 4.2. Community review and technical quality are of course important and being attended to. The effort to find and fix issues with this change speaks for the attention to technical quality. I am simply asking how much time is needed to review.
> >> > >>> > >>>> > >>>> 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 > >
