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 t...@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 <t...@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 t...@blender.org www.blender.org >> Blender Institute Entrepotdok 57A 1018AD Amsterdam The >> Netherlands >> >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
