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