[Bf-committers] Blender Release cycle proposal

[Ton Roosendaal]

Hi Erwin,

It's not ignored, but I try to solve conventions for releases first.

Next to that, a switch to a new versioning system will have to come  
from within the active team too, we talk about it regularly. Is under  
review.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 19 Aug, 2011, at 16:40, Erwin Coumans wrote:

> Hi Ton,
>
> Several developers requested to use git, or similar, but that  
> request seems
> ignored.
>
> What are the reasons to avoid a distributed revision control system  
> and
> stick with svn?
> Thanks,
> Erwin
>
>
>
> On 19 August 2011 07:16, Ton Roosendaal <ton at blender.org> wrote:
>
>> Hi all,
>>
>> Trying to incorporate all reviews & crits, here's a summary of where
>> we can head to:
>>
>> 1) What we agree on (strict :)
>>
>> - Trunk is by definition stable and usable
>> - Branches & patches only get applied to trunk when stable & finished
>> & documented sufficiently.
>>  (within the specs module owners defined)
>> - No branch/patch should get rushed in by only popular demand.
>> - No release happens with regressions compared to previous release(s)
>>  (with exception what announced/agreed on)
>> - For each release, we define as early as possible the targets
>> (mergers, patches, etc) and timeline
>> - We release as often as possible
>>
>>
>> 2) What we keep free:
>>
>> - Module owners/teams can define what goes to trunk (stable  
>> features &
>> fixes) and what should be branch development.
>> - Release cycle target is 2 months, but should not frustrate quality
>> or running projects. If not practical, the cycle can get extended as
>> much as needed, preferably not more than a month though.
>> - Patch/branch developers are expected to seek themselves active help
>> and involvement to get things approved.
>>
>>
>> 3) Love for everyone!
>>
>> - BF/BI team assists on reviews, but we'd need many more devs to help
>> with it.
>> - Get artist-buddies for coders
>> - Involve stakeholders better.
>> - Decision tree: always strive for consensis, starting at lowest  
>> level
>> (everyone here), if not possible then module owner/teams, then bf-
>> blender project admins. I'll act when no agreement can be reached.
>>
>>
>> A graphic with the cycle: (summarizes most of Thomas' wiki page)
>> http://www.blender.org/bf/blencon.jpg
>>
>> Thanks,
>>
>> -Ton-
>>
>> ------------------------------------------------------------------------
>> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The  
>> Netherlands
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers