Meeting minutes, 12 September 2010
This week they discussed BMesh, the GSoC Unit testing, the broken OBJ exporter, bugs and more. They also need some helps on those bugs in the tracker.
Ton Roosendaal writes:
Hi all,
1) Current projects
- Joe reported he’s still working on bmesh, part-time now since school demands attention too.
- Campbell mentions Leif’s GSoC project (auto test) would have helped us with release (OBJ export broken), Leif will work on updating branch for latest svn.
2) Blender 2.5x
- The broken OBJ export will be in release for now, better to wait a few days for other urgent fixes, and decide todo an update ‘a’ next week?
- Beta builds are online and synced with mirrors, the logs and webpages for the 2.54 beta launch are ready, all will go life after meeting
- Bug tracker still is in the very high numbers… help there is still much appreciated. Campbell, Nathan, Janne and Diego will keep attacking it the next weeks.
- Campbell will fix the keymap install (paths) issue, Martin Poirier reviews.
-Ton-
How come we don’t have more people working on this BMesh. It seems everything posts about BMesh is about further delays.
@ young_voter though Bmesh contains contributions from several people, as far as I understand it is the brainchild baby of just one, Joseph Eager. If you have written code, then you know how hard it is to understand exactly where and how to help push along someone else’s project.
@3dementia you got a point here my friend but I have to disagree with you in some details. Well engineered software should be easy to read and to maintain, assuming of course that everybody involved has knowledge and skills to do so and in Blender case, I think we can safely assume so. The thing is, BMesh is going to be the Blender’s Duke Nukem Forever and this give credit for your statement. Sad enough I put myself in the position of complete frustration when talking about Blender code. I’m a skilled software engineer with years of experience ranging from assembler to C++ languages, with good math and graphics theory on bag and still I’m incapable to contribute to Blender by the simple fact that there is no documentation about the whole architect, subsystem, etc. Due the complexity of the Blender software no one can be a developer without deep commitment to the project and this IMHO is a big limitation in the Blender’s bazaar strategy. I know it sounds like a limitation of myself and that’s exactly the point. Blender development ecosystem should be opened in a grater level, one where casual developers like me could contribute code and bug fixing as demand gets bigger, and for this we need better documentation and better project management.
Again, this is just me complaining about my own limitations as a developer incapable to fit in a chaos style bazaar project. Kudos for all Blender developers.
good points Perbone:
– casual programming for blender seems hard without a deep involvment,
– kudos to the current programmers, you’re heroes :-)
Oh. I understand the need for documentation (I’m a computer science student and had read some undocumented codes). Well, thanks and good luck to blender developers.
So, if you aren’t a programmer, this release is just bug fixes, right?
Don’t get me wrong, that’s great news, I’m just asking…there are no new features, I guess.
The wait for GI is not over yet, shame.
@Juan GI comes in 2.6, if I understand it right. The beta series is almost only bugfixes.
I can confess, that I’ll really switch to 2.5X (2.6X) series after BMesh integration and taking modeling tools at least to the state they are in 2.49. Until that I’ll stick with 2.49, because I model a lot.
Another thing is Python API still changing in 2.5, so I will rewrite my crucial scripts I need for my work after API freeze.
Though I’d like to say a big thanks to all developers! Your work is significant and well appreciated! ;)
@Juan Romero and @dsavi
What does GI stands for?
@ertet GI stands for Global Illumination
@Perbone same here, i fully agree. there is so much talking about python api not consistent yet. python api here, pyhton api there. as if that would clear up the whole mess. a nice and sweet guide through the source code would be so nice. even if “casual programmers” may not be given svn commit access, they could certainly help finding bugs and show a fix that has to be reviewed by the “real” ones. blender feels like free beer, if you know what i mean.
Blender betas nowadays are feature complete (even if 2.4x features are still missing), just bugfixing is allowed. So all work in other branches are being postponed to post 2.6. The last work ported to trunk was the sculpt SoC project, and some parts of it were left out. The other projects will have to wait. This has been stated many places over blenderartists and blender.org.
And as usual with open source projects *with* management and complex like Blender: You have to prove your skills before you can get the keys. But nobody is stopping you to go to #blendercoders on freenode and do some questions there… and send patches to the bugtracker for review.
And about python API. is a needed thing to extensions and plugins so a well established and well thought API is need to make things work with all possible cases: enternal renders integration, exporters, external post processing modules, etc. And is a not trivial thing to make things “stable”… Not even commercial software can manage to maintain a stable API for 2-3 years without breaking something (e.g. Autodesk software as an example). Only Windows OS has done a similar thing in the past, but that’s why has become to be a beast of incredible proportions nowadays
@j. i think you missed the point. did you read Perbones post? imho a documentation to the code would go well with the project. what i think is that a lot of capable developers get scared away from what Perbones called the “blender development ecosystem”. i think the term is quite appropriate. some helpful documentation would speed up development on the long run, due to more guys (dare to) take part in it.
and yes, python api is important. its high priority. no doubt about that. still, i would prefer “we made an introduction to the source code for all those wannabe-hackers out there” rather than “we made the python api stable” in the meeting minutes blog. is there anything wrong with my opinion, j.? ;)
i too agree with Perbone. well docs will provide less complexity bringing more contributors to the blender