[rules-dev] [Proposal] Less horrible releases: 1) Don't add new features after CR1 is branched

Toni Rikkola toni.rikkola at gmail.com
Tue Jun 28 06:23:17 EDT 2011


+1 candidate release should already have all the features the release will have. There should also be enough time for people to test CR releases before we release final.

On Jun 24, 2011, at 1:53 PM, Michael Anstis wrote:

> +1 to no new features after CR1.
> 
> On 24 June 2011 10:19, Jervis Liu <jliu at redhat.com> wrote:
> On 2011/6/24 12:49, Geoffrey De Smet wrote:
>> 
>> Hi guys,
>> 
>> This release (5.2.0) has been pretty horrible.
>> We 've lost lots of time on:
>> - cherry-picking commits
>> - testing everything again and again (and again) because the last cherry-picked commit just changed everything again
>> Which results in months of delay (branch date was 28-APR and release date was 23-JUN).
>> 
>> Let's make the next release less horrible :)
>> I believe this organization problem is very easy to fix, by introducing this rule:
>>   Don't add new features after CR1 is branched (on the CR/final release branch)
>> 
> +1
> 
> Jervis
>> What do you think? Do you think this is a good idea?
>> -- 
>> With kind regards,
>> Geoffrey De Smet
>> 
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
> 
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
> 
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110628/b4d57a2c/attachment.html 


More information about the rules-dev mailing list