[Bf-committers] Blender irc developer meeting, May 1 2011
Ton Roosendaal
ton at blender.org
Sun May 1 18:29:04 CEST 2011
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
More information about the Bf-committers
mailing list