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