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 etc. - 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 doable. -- Prasanna., ------------------------ Powered by BigRock.com
