cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: [DISCUSS] Should we be releasing -beta releases?
Date Mon, 27 May 2013 07:53:16 GMT

On May 24, 2013, at 12:26 PM, Chip Childers <chip.childers@sungard.com> wrote:

> On Tue, May 14, 2013 at 10:41:30AM -0400, Chip Childers wrote:
>> As a way to get more user feedback on our major feature releases, what
>> does everyone think about releasing one or two -beta releases for each
>> major feature release?
>> 
>> This might fall in line with some of the stated concerns about our
>> release schedule (see [1]).  I've stated a desire to be quicker about
>> our releases (my vote was 4 months).  I've also been saying quite
>> publicly that we should never release if we know about upgrade issues
>> (that's the cost of having actual users of our project, which I'm more
>> than willing for us to pay).
>> 
>> Perhaps -betaX releases would be helpful to get attention from the users
>> to test the release (including upgrade paths).  The stated assumption
>> could be: -beta releases are not releases that can be upgraded *from*,
>> but are intended to help support testing by end users that want to check
>> the upcoming release against their expected feature set and upgrade
>> path.
>> 
>> I would see the first -beta-1 being released about 1 month after feature
>> freeze.  For example, for 4.2.0, it would be on 2013-06-30.  I would
>> only do a -beta-2 (or later) beta release if required due to testing
>> results.  I would also suggest that the -beta-* releases would *not*
>> have any particular quality criteria (well...  perhaps minimal, like
>> blocking on issues that fundamentally make the software unstable).
>> 
>> I'm not sure about my own proposal here, but I wanted to throw it out
>> and see if any of you have feedback / thoughts.
>> 
>> -chip
>> 
>> [1] http://markmail.org/message/3ctdwor5hfbpa3vx
> 
> To summarize the discussions of this thread:
> 
> 1) The idea of ensuring that we get user testing of release candidates
> is one that most agree with.
> 
> 2) Concerns were raised about the overhead of "officially" releasing
> beta releases, especially if there is any expectation that there would
> be an upgrade path from a -beta to an official release.
> 
> I'd like to simplify this by saying that we should actually plan on
> announcing the start of each round of voting on RC's to the users@ list.
> We can get feedback from them on each round.  

Why don't we include users@ in the voting thread in the first place ?
The entire community can vote, correct ? committers and non-committers.

Asking @users for feedback make it sound a little bit like feedback is welcome but not voting.

> And while I don't really
> love having a bunch of rounds of voting, 4.1.0 has basically proven that
> user engagement testing the RC's is critical.  I think that we might
> also consider (at a release manager's discretion) periodically
> announcing a request for testing of the feature branch's code during the
> QA part of our release cycles.

+1

> 
> Shout if you disagree.


Mime
View raw message