[Bf-committers] Blender Release cycle proposal
erwin.coumans at gmail.com
Fri Aug 19 16:40:00 CEST 2011
Several developers requested to use git, or similar, but that request seems
What are the reasons to avoid a distributed revision control system and
stick with svn?
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)
> 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
More information about the Bf-committers