On Tue, Jan 29, 2013 at 1:16 PM, Kelven Yang <kelven.y...@citrix.com> wrote: > It will be a long journey to shape CloudStack into a better > next-generation structure, this is just a start and this is why we'd like > to get it more early than later. Otherwise, it may take another 4 months > to get the idea into CloudStack main stream.
Actually, let me clarify the point about "another 4 months", just so that we are all talking about things in the same way. IMO, there is really only one particularly sensitive time for changes to hit master: just before we cut a release branch for stabilization. Let's use javelin as an example here. Ideally, it would have come in early in a release cycle, and for *master* that starts right after a release branch is cut. Once we have a release branch, master is wide open for changes that will be in the *next feature release*. That's actually 4 months of opportunity to get things into master for the next release. The fact that the release branch is then going through stabilization for 2 months following the release branch being cut shouldn't effect our thinking in master. Certainly bug fixes will be harder to port between the release branch and master if a big change goes into master, but that's the reality of trying to evolve an architecture over time. Reiterating that I'm personally OK with the current javelin merge plan (since I proposed it), I'd like to state for the record that we should all be cognizant of the different levels of concern around architectural changes throughout the 4 month release window. Naturally, the concern about master's stability increases steadily throughout the 4 months leading up to the next release branch, and as things get closer and closer to the release branch being cut the more important it is to keep the architecture stable. If I had a major architectural proposal that I was working on, I'd be trying to get it in shape to come into master only a couple of weeks after a release branch is cut. That gives the rest of the community (1) time to help test and stabilize it, as well as (2) a clear target architecture for feature development hoping to make it into a specific feature release. If we continue to use a time-based release cycle, the best thing we can do as a community is to develop an internal project rhythm that respects the needs of everyone involved. I'm very excited about the architectural journey you mentioned, and you are right to state that we are only at the beginning of it. Can we agree that the future would be better for the whole community if we try to adopt architectural changes earlier in a release cycle? -chip
