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