cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [MERGE][ACS41] javelin to master
Date Tue, 29 Jan 2013 18:39:38 GMT
On Tue, Jan 29, 2013 at 1:16 PM, Kelven Yang <kelven.yang@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

Mime
View raw message