Re: [Bf-committers] Blender Release Cycle
Hey Michael, This is everything else than foolish. It would be if we would continue like before, but we intend to only merge features into trunk which are really finished already! In trunk then the projects still have a few weeks to fix bugs and improve it if necessary. If the feature is not ready or still unstable at the end of week 6, project admins will decide if it will be removed again, it's that simple. We won't have any problems if we stick to that: 1) Only features which are finished and code is reviewed well can be merged. 2) If at the end of a cycle the feature is not ready to be released, remove again until next cycle. Thomas Am 16.08.2011 09:35, schrieb Michael Fox: I never agreed with the 8 week release cycle anyway, as it causes you to rush your work resulting in ugly hacked together code and features and results also in releases with little substance. Such a cycle works for Chrome and FF because they are at each other throats trying to out do each other and fix 100s of bugs a day. This proposal for 8 weeks is foolish, we have always prided ourselves on clean(ish) code and well thought out mature features and releases filled to the brim with stuff and never put 1 bug above another all bugs are the same and the community loves us and loves blender for that as we don't belittle their problems. i know i should have said this earlier but what i say has very little meaning anymore like what i said here will be ignored as always ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Release Cycle
On Tue, Aug 16, 2011 at 5:35 PM, Michael Fox mfoxd...@gmail.com wrote: On 16/08/11 14:55, Campbell Barton wrote: On Tue, Aug 16, 2011 at 7:52 AM, Michael Foxmfoxd...@gmail.com wrote: On 15/08/11 22:40, Sergey I. Sharybin wrote: Hi, devs! We've already got thread about release cycles, but it was a bit long and seems like there's no final decision made. We've discussed that proposal with Campbell and also investigated why we've run into some problems with current release. There are some comments which i'd prefer be final decision about our release cycle (most people are already ok with it, just to make things 100% clear). Few first weeks of cycle (B-Con 1 and B-Con 2) aren't so critical for this discussion and we've already agreed with this levels. More critical to make work clear in few weeks (1-2) before release (i mean before starting commiting new splash/changelogs and so). What is needed there: - Only _critical_ bugs should be fixed. Critical doesn't mean i can make blender crash in few clicks but it mostly means this bug was introduced in current cycle and it stops normal workflow. If this bug was present in previous release or if it's not making general usage unusable we'd prefer to keep this bug untouched. Fixing such bugs wouldn't make real sense on general workflow and if it wasn't noticed in previous release then it doesn't annoy artists. But fixing such bugs easily produces new bugs which difficult to predict and we wouldn't have enough time to test everything. - We need clear FREEZE and UNFREEZE AHOYs. If freezing will happen a bit earlier -- it's not so critical. But unfreezing should be done quite accurate -- when everybody who is familiar with making release would say it's ok to unfreeze. - We'll need tag for every release. It should be created even for initial release (not corrective release like 'a' or 'b' releases). this is needed to make platform maintainers' life more clear. If stopper is discovered during archive preparation, fix for this stopper can be easily commited to trunk and merged to tag. It'll help a lot for release process when most of core/BF developers are offline -- no need to wait someone to prepare archive. - Most probably we'll need guy who is familiar with svn who will make tag and solve possible issues of platform maintainers. It shouldn't be constantly defined developer, prefer to choose one for each release -- it's needed to be sure he can be available during release. - So, FREEZE happens, new tag is creating and AHOY could happen. Day or two after this normal life of trunk could be restored. But _nobody_ should commit anything than fixes for stopper/fixes for build environment until _official_ unfreeze. Even commit of stylefix could be confusing in the future (if more serious problem was discovered, i.e.). - If 'a' release is needed, we shouldn't re-tag. We should merge fixes for _stoppers only_ into tag and do not include fixes for all bugs which were made since release. This is a way to avoid 'b' releases. So, short summary: fix only _really_ critical bugs last week before release-related commits; make clear FREEZE/UNFREEZE messages in ML. create tag for release just before AHOY, if 'a' release is needed only stoppers for previous release (for which 'a' is creating) should be ported into tag. I hope only Campbell/Ton/Brecht make minor changes to this message or write things i've forgot to tell about. But again. i don't want this message start new discussion thread and i hope it'll be final decision now. I thought this is what we already do, its just in the 2.5 series we have become very lazy in these regards, now that 2.5 is final and stable, we should really adopt our old methodology again with no set freeze period, we aim for a date and set freeze a few days before it, and only release if the code is deemed releasable This goes against the fixed 8 week release cycle, release when its ready might sound good but blender is getting so big that we can always point at some part (py-api/input-support/bug-on-some-OS/some-new-library/ffmpeg/sequencer) and say its not ready *and be right*, but then end up not releasing even though many bugs _are_ being fixed between releases and useful improvements made. With time based releases only consider show-stoppers as new bugs which were introduced since the last release or anything that makes blender unstable for common use. I never agreed with the 8 week release cycle anyway, as it causes you to rush your work resulting in ugly hacked together code and features and results also in releases with little substance. Such a cycle works for Chrome and FF because they are at each other throats trying to out do each other and fix 100s of bugs a day. This proposal for 8 weeks is foolish, we have always prided ourselves on clean(ish) code and well thought out mature features and releases filled to the brim with stuff and never put 1 bug above
Re: [Bf-committers] new dependencies for (spacenav / ndof / 3D mouse) support
Mike! I have definitive proof that what I expect makes sense, even BigBuckBunny likes it that way! you can't argue with the big passive aggressive bunny! http://youtu.be/lI2KIjSkbzQ?t=1m30s Daniel Salazar 3Developer.com On Mon, Aug 1, 2011 at 10:09 AM, Stephen M. McQuay step...@mcquay.me wrote: I installed from source and everything worked ... except I agree with Daniel: everything seems backwards. I'm sure it could be chalked up to a preferences thing, but when I used my first spacenav device 5 years ago (3D parametric CAD stuff using Unigraphics) it was definitely in a move device as you'd expect to move the part in 3-space kinda way. I also build the little config gui thing and saw that one could invert axis, but I haven't tried that out. Anyhow, there are my two cents. -- Stephen M. McQuay http://mcquay.me/vcf ___ 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
Re: [Bf-committers] OpenMP on osx
On Tue, Aug 16, 2011 at 8:54 PM, Tobias Kummer supertoi...@gmx.net wrote: Hey there! I just realized that when using an OpenMP enabled build on osx (cmake), all simulations and baking run terribly slow. When I compile the same revision with OpenMP disabled, it uses one core at 100% and is MUCH faster. Can anyone confirm this? Are there known problems with OpenMP on OSX? Greets, Tobi At the blender institute we had the same problems and it seemed to be because of the processor (core2's were ok but i7's had performance problems), rather then rebuilding you can set the OMP_NUM_THREADS environment variable to 1. We could make blender detect this on startup and set OMP threads to 1 based on the processor - using a shell script or perhaps it can be done in blender's main function on startup. -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenMP on osx
Oh yes! I can confirm. It has been a problem for a long time, I first noticed it about six months ago when I got a new machine. It's been discussed over at IRC, but no resolutions yet. My Mac Pro cannot really be used for simulations at all, my MacBook Pro is a lot faster. This is a bit weird since my pro is an 8-core machine, while the laptop is dual core. I tried compile using newer gcc versions through macports, but always ran into (for me) unsolvable errors. -mats On 16.8.2011, at 13.54, Tobias Kummer wrote: Hey there! I just realized that when using an OpenMP enabled build on osx (cmake), all simulations and baking run terribly slow. When I compile the same revision with OpenMP disabled, it uses one core at 100% and is MUCH faster. Can anyone confirm this? Are there known problems with OpenMP on OSX? Greets, Tobi ___ 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
Re: [Bf-committers] Blender Release Cycle
On Tue, Aug 16, 2011 at 2:55 PM, Campbell Barton ideasma...@gmail.comwrote: With time based releases only consider show-stoppers as new bugs which were introduced since the last release or anything that makes blender unstable for common use. For what it's worth, I really like the idea of time-based releases, but there's a big caveat which I think hasn't been properly solved yet. The whole idea is based on keeping trunk stable (i.e. not allowing it to go into long periods of instability while coders work on things heavily in situ), and to use branches for work-in-progress stuff and merge them into trunk when they're properly ready and won't disturb trunk. This is great in concept, but it's also this part that is the problem here. Time and time again, branches aren't tested well enough before merging. I've seen it so many times over the last several years - features getting added without having major bugs found by testers, dodgy code getting added without a proper code review or oversight from other committers, and when these things happen, the code tends to stick around. (I'm sure I'm not blameless in the past here myself, either). For the last couple of releases it wasn't so bad since there weren't any major new features (but even then there are still plenty of bugs), but I'm a bit concerned about what will happen especially now the kids on the internet are getting all excited about opening the floodgates of new code for 2.6, which probably hasn't had nearly enough testing/review either. I think for this to work, project admins will need to be much stricter about what is acceptable to go into trunk. If there are still signs of problems in a newly merged bit of code when coming up to release time, it needs to be ruthlessly pulled out before release (in order for the developer to work on it some more before the next cycle), and not just allowed to slip through. I think if the last year or two of blender development has shown anything, it's that quality control is a huge issue, and that blender needs *quality code* much more than it needs *more code*. It's quite an inefficient use of resources when the more experienced and skilled blender developers (the ones on the BF payroll) are spending their time bogged down fixing silly bugs. At least when I was doing it, I found it rather demotivating too. So I think this shorter release cycle can be an improvement, but if and only if it's taken as an opportunity to be stricter about the inclusion of insufficiently tested/poorly written code. If not, it'll probably make things much worse. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Release Cycle
On Wed, Aug 17, 2011 at 10:47 AM, Matt Ebb m...@mke3.net wrote: On Tue, Aug 16, 2011 at 2:55 PM, Campbell Barton ideasma...@gmail.comwrote: With time based releases only consider show-stoppers as new bugs which were introduced since the last release or anything that makes blender unstable for common use. For what it's worth, I really like the idea of time-based releases, but there's a big caveat which I think hasn't been properly solved yet. The whole idea is based on keeping trunk stable (i.e. not allowing it to go into long periods of instability while coders work on things heavily in situ), and to use branches for work-in-progress stuff and merge them into trunk when they're properly ready and won't disturb trunk. This is great in concept, but it's also this part that is the problem here. Time and time again, branches aren't tested well enough before merging. I've seen it so many times over the last several years - features getting added without having major bugs found by testers, dodgy code getting added without a proper code review or oversight from other committers, and when these things happen, the code tends to stick around. (I'm sure I'm not blameless in the past here myself, either). For the last couple of releases it wasn't so bad since there weren't any major new features (but even then there are still plenty of bugs), but I'm a bit concerned about what will happen especially now the kids on the internet are getting all excited about opening the floodgates of new code for 2.6, which probably hasn't had nearly enough testing/review either. I think for this to work, project admins will need to be much stricter about what is acceptable to go into trunk. If there are still signs of problems in a newly merged bit of code when coming up to release time, it needs to be ruthlessly pulled out before release (in order for the developer to work on it some more before the next cycle), and not just allowed to slip through. I think if the last year or two of blender development has shown anything, it's that quality control is a huge issue, and that blender needs *quality code* much more than it needs *more code*. It's quite an inefficient use of resources when the more experienced and skilled blender developers (the ones on the BF payroll) are spending their time bogged down fixing silly bugs. At least when I was doing it, I found it rather demotivating too. So I think this shorter release cycle can be an improvement, but if and only if it's taken as an opportunity to be stricter about the inclusion of insufficiently tested/poorly written code. If not, it'll probably make things much worse. cheers Matt Hi Matt, I'm with you on this, more often then not big changes == breakages/bugs/dropping-support-for-corner-cases/glitches. I think problem with code quality of branches needs to be solved by some tangible changes to the process and what we accept. like saying lets not write buggy code - it sort of meaningless unless its followed up with some real changes to how we work. Here are some suggestions *disclaimer that this is colored by my own experience preferences, I may be overlooking some issues* 1) don't accept changes from branches that are outside the branches scope. Sounds obvious but devs add features or fix bugs (in gsoc too), which are not related to the branches main purpose, IMHO this is really bad for a few reasons. * makes reviewing the branch difficult since its not always obvious why the change is made, Ive had to follow this up with the authors - sometimes to find it was some test left in by accident or just a change they thought was a better default. * adds communication overhead to branch review OR it just slips through into trunk which can also be really bad if the change has unforeseen side effects. * makes svn annotations harder to follow when new bugs resolve to lines from a merge which isn't even supposed to be touching this area. For devs who already made unrelated changes in their branch it just means submitting unrelated changes as patches on trunk. 2) Code should be reviewed - as in a developer read over the changes, sounds obvious too but currently we don't always do it. Of course code review still allows for bugs in behavior, but from reading diff's some bugs are obvious. With large changes to blender which I find suspicious, I'll copy blenders source tree and view the source tree before/after the change using a visual diffing tool - since reading the diff on its own isn't easy to follow. I did this recently from a merge and found lines like Fix this tomorrow, and some obvious hacks that should have been dealt with before the merge - This was in code I wrote so I'm confident they were not-good-changes, but the point is nobody reviewed the branch! We have 4 employees for BF now, we should be able to manage this? :) 3) Improve testing on branches This is hard to enforce, I think we can only try to help users to get
Re: [Bf-committers] Blender Release Cycle
1) don't accept changes from branches that are outside the branches scope. Sounds obvious but devs add features or fix bugs (in gsoc too), which are not related to the branches main purpose, IMHO this is really bad for a few reasons. On a related note, I think it might be helpful to break branches up into a series of smaller patches. I think a lot of branches can probably be split into at least three sets: 1) First would come very general changes to existing code. This would include things like bug fixes for trunk, but also things like adding an extra parameter to a Blen[lib/kern] function to make it more general, or adding better comments to an existing module. There are often a lot of changes like this that can be reviewed entirely independently of whatever feature the branch is actually focused on. 2) The second set would be more in-depth refactoring within one or more modules. For example, a new sculpting/painting mode might want to refactor some of the generic paint stroke code to expose some new feature to all the painting modes. Or maybe some new data structure has been created that could be submitted as a new Blenlib interface. Essentially this set is more complex/bigger changes than the first set, but still stuff that can be reviewed independently of any new features. 3) The third and final set would contain the new feature itself. The goal here is that this patch should be as simple as possible, relying on refactoring and infrastructure changes from the previous two sets. Obviously the above three descriptions are a bit general and would need be interpreted a bit on a case by case basis, but I think this could be a helpful guideline. I've been doing something like this for my own experimental patches; there are a number of new features I've worked on like Ptex and the skin modifier that simply aren't ready to go in trunk yet, but I've still been able to extract some useful code and put it in trunk (things like adding better comments to the PBVH struct, cleaning up the GPU VBO code, and refactors in the paint code.) -Nicholas ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Release Cycle
On Wed, Aug 17, 2011 at 3:06 PM, Campbell Barton ideasma...@gmail.comwrote: Here are some suggestions *disclaimer that this is colored by my own experience preferences, I may be overlooking some issues* +1 ! Here are some more ideas of mine: 4) Improve testing on branches (continued) The problem with branches is that not many people use them, everyone just wants to use trunk, because that's where the action is. At least from my perception, most of the time when people do use branches, its just to see some new feature, poke at it a bit, then leave it alone - not really pushing it to the limit in real work. A solution for this could be to make trunk the 'boring' branch with mostly just bug fixes etc, and have a development branch which people can merge their own branches into for testing (like the gsoc salad branch). Another idea that Ton had many years ago which I still like is for coders to find an artist 'buddy' to help them throughout the development process, someone with whom the developer can work with closely for feedback and testing. A good portfolio of work done with a branch can go a long way to vouch for its readiness for inclusion into trunk. 5) All new features are developed in branches For all substantial new features everyone must use branches - core devs and module owners included. Module owners are capable of committing weird/bad/unreliable/poorly tested code, just like anyone else, and this code should be tested in quarantine as well. 6) Documentation Ton says this every year or so, but anyway again - before review/merge into trunk, a new feature should have at least a minimal form of user documentation, and some brief code/design documentation. Shouldn't have to be too comprehensive, but should at least help reviewers/module owners/etc understand the code they're reviewing, or find any design flaws up front. 7) Enforcement Technically there are policies like these already in place (eg. should have documentation) but they're never/rarely enforced. Most of the time now, if people commit weird/bad/undocumented/untested stuff to svn everybody just shrugs their shoulders and moves on. These will only work if project admins and committers agree to call each other out on these points and also accept it when they have to abide by them. So if something is checked into trunk without going through a branch, or without proper documentation, or without enough testing, it must get reverted out of trunk. There can't be a stigma or fear of hurting people's egos here, it's just a matter of doing what's right for the project. And ideally with a short release cycle, it's not the end of the world if your code doesn't make it in to a release anyway, since the next release is just around the corner. Anyway, I really do think this is a serious issue - the last couple of years show that pretty well, and there's the potential for it to get a lot worse as blender gets more and more complicated, and takes on new scope. In the end, limiting the addition of code that's not up to scratch results in more, better features, as less core dev time and resources are spent on bugs, and more on the cool stuff! cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
