cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prasanna Santhanam <>
Subject Re: [DISCUSS] ACS Release 4 month v/s 6 month
Date Tue, 23 Apr 2013 14:18:53 GMT
The problem (I am beginning to realize) with extending the release is
the temptation to cram in more features. May be use the collab
conference to improve release management aspects. What we did right
in 4.1, what went wrong, how to better plan 5.0. And that can happen
with a 4 or 6 month cycle. I understand the exclusive nature of this
but I do think that everything must/should be brought back to the
lists judiciously. 

To me making our release cadence easier to follow is an important step
towards bringing in more contributions. If that happens soon the
better - offline or online. Either way the effect is going to be felt
on the list since release management affects everyone.

IMO, even with a time-based release we need to think of things like:
 - Is this proposal targeted for the next release going to be
   disruptive to others
 - Are we changing architecture aspects of the system - that work must
   happen well in advance.
 - What features are possibly stalled by architecture work/refactors
 - When to pull the plug on proposals to make it to the next release.
   Or do we just consume everything until code freeze
 - What gets manual tested, what gets automated. Are we reviewing our
   test plans?

It seems like anything that's had a discussion and a wiki page under
4.2 release is already targeted for that release now. Just go look at
it. It's massive! :)

On Mon, Apr 22, 2013 at 08:13:55PM -0700, Edison Su wrote:
> +1, on the automation test. When will we have good automation test?

After a long-winded struggle from our startup days - automated tests
are _finally_ becoming a priority. That in itself is a great leap
forward for us as a project. Until now I'd say testing hasn't received
the same love as the love for adding new features. But it'll take us a
release or two to build up those test suites strong enough to ensure
that our releases are not delayed. Time is nigh to think along the
lines of testability of features being merged, proposed and churned in
our topic branches.

I'd like to see the day when our "threads on release management" grow
shorter than those done as reviews for patches and topic branches. We
need to seriously start paying attention to:
 - The work happening around in those silos (topic branches).
 - And to the bugs users have been reporting. 
 - Reviews of test plans is going to have to be considered seriously
 - During those reviews think about automating the QA tests. If
   framework support doesn't exist, extend the test framework to
   support that.

It's great that we at least begin to add tests when we need our
feature merged now. Where we need to get to is start thinking about
testability from the beginning of feature planning. All of this if we
do even with a reasonable efficiency I think 4 months should be


Powered by

View raw message