[Bf-committers] Blender irc developer meeting, May 1 2011

[Ton Roosendaal]

Hi all,

1) Blender 2.5x project

- Bug tracker went up to 169 open issues. All efforts to bring this  
back are welcome. We still try to work on stabilizing first. Target  
would be a 2.58 release within 6-7 weeks (end june).

- Question was how to define which small features or patches can be  
added now. Suggested strategy for this is:
  1- maintainers/owners need to approve first
  2- should be fitting in roadmap for code, and be well maintained &  
stable
  3- try to only do this in May, to keep June as testing period.

- "Dynamic Spacebar" script: discussed was if this could be default  
active. Ton prefers to have the script behave different first; it now  
just hacks the Search Menu operator, disabling access to it at all.  
Ideally it should be an own operator. Having the 'search button' in  
top of menu also responds weirdly to direct keyboard input.

- Windows Installer still has several reported issues, needs more  
work! Preferably not postponed to week before release.

- Testing and RC cycles: we should try to enforce more and better code  
reviews... especially in RC period having more people check commits  
would prevent errors.

- Janne & Genscher: check on Joe's commit for cloth collisions, could  
this go back? Joe: a short log or doc about the functionality and/or  
with test cases would be welcome to help them.

- Sergey updated FFmpeg for linux, needs tests.

2) Current branches

- Lukas Toenne has 'paged particles' code waiting, Janne checks

- We need general coordination between all projects that (will)  
utilize Nodes: game logic, shaders, compositor, modifiers, particles,  
constraints.., Brecht will coordinate.

- Also openCL usage and APIs would need to be well aligned among  
branches.

- Nurbana: still on the list for Sergey to check further on

- Other branch devs and ex-GSoC students, please report back!

3) Google Summer of Code

- A proposal is being reviewed to have students share branches. Small  
teams of 2-3 students could work on same branch, provided code won't  
conflict for future merging back in trunk. Benefits are that compile  
issues or trunk-syncs can be solved together.

- Ton says: use veggie names for the branches! :) (carrot, parsnip,  
onion, potato)

- Another idea is to use a "staging branch", which means to have a  
trunk synced branch where the gsoc projects merge to regularly. Either  
weekly, or on moments a student likes to get official testing.

- Dalai proposes to use the review tool extensively as well. This is  
being reviewed. Brecht mentions that for branch commits it's not much  
required either...

- For students: commit rule #1: only when it compiles + runs Blender  
fine!

4) other projects

- Cycles wiki
   http://wiki.blender.org/index.php/Dev:2.5/Source/Cycles

- We'll open a temporarily mailing list for people who want to be  
involved with design and implementation:

http://lists.blender.org/mailman/listinfo/bf-cycles

Thanks,

-Ton-

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