[Bf-committers] Official Automated Builds
Hello guys, I see you have mentioned BuildBot as an option for continuous integration. I work for a computer science research lab andwe have set up a buildbot to control the quality of our code. I wrote a wiki page about this:http://openalea.gforge.inria.fr/dokuwiki/doku.php?id=documentation:tools:continuous_integration It describes (vaguely - because there's undisclosable stuff too) or gives pointers to how we did this:- buildbot server and slave configuration- virtualboxes and ssh access to them- auto-start of vboxes and of buildbot slaves Hope this helps! If you want details, I can dig in my memories and try to help!Daniel ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Roadmap for 2.5x - 2.6x - beyond
This is great. +1 for Brecht's 8-week release cycle. My only concern is whether some users might get confused about the release versions. I think that instead of having 2.58 as the last release, we should skip to 2.60, and make it the base release for the 2.6x series. This would make sense (I assume) to the majority of Blender users who understand (Again this is just taken from what I've observed, correct me if this is not the case) 2.5x to be a development series. Everyone is waiting for 2.6 and it will be a great marketing opportunity for Blender to be able to say Come get Blender 2.6!, much like how other software releases, for example: Maya 2011, Lightwave 10, ZBrush 4, 3D-Coat 3.5, thus we have: Blender 2.6. I think this will also make more sense to developers, in that we have 2.60 as the base and we start working up and adding stuff from there, instead of working from 2.58 up to 2.60 and having a bunch of new features in 2.60. Just my two cents, Jonathan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Official Automated Builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14.3.2011 12:04, Nathan Letwory wrote: On 14.3.2011 4:22, Brecht Van Lommel wrote: Mainly my motivation is getting good reference builds for bug reporting, and finding and solving build and installation issues for releases sooner so we can do more efficient releases. So the intention for these builds would be to be identical to release builds. I can hook my release building box to the system, should be no problem. I have had good experiences with buildbot. Oh, and one thing I forgot to mention. As a requirement for whatever we choose: it must be usable with SCons. /Nathan - -- Nathan Letwory Letwory Interactive | Studio Lumikuu http://www.letworyinteractive.com | http://www.lumikuu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNfejLAAoJEKtfN7KsE0TtTLsH/1AiZpGxCI2ERbCVD15Y2r6l 53BLv+zAor2Cv0i4ykFodZJC1kLkoKLFtR/pniNTVnxxu8Qps8rQ+IV/BpXYfZKk eu//RHq9BPZ+lbnTqZNkBTfxRRl2FDWNQZsy/atoAArJveY039cyce1dZT7NZ/MA Pc2ZbzPaiehWfJ6XanMhS494ySrtyss7ESCBggKnml2MCzaiJOyyfm7zxqj9mBhz frH5P2ZN7D0Xuwj+SqFITL9nWlzBlJPg00ZnEzM7Pv3P7tkXsSellGRC1uSgTi4t fe1tCrLm3yCAGUMAIOsb7W+T+82ADXafnJfxRLE9cpuFcWCJdB/YYJDHWuCBO20= =UCVJ -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Roadmap for 2.5x - 2.6x - beyond
Am 13.03.2011 15:52, schrieb Brecht Van Lommel: Hi, [...] There's this dynamic which I think we should try to break: unstable features push back release dates, then after a while, core developers in other areas get impatient and add another unstable feature, which agains pushes things back further, while branches get even bigger and harder to merge. I am not a developer, but this was my feeling the last years, thanks for pointing this out so clearly. Also for the rest I would fully agree on (especially the part with the If a feature is not stable or not documented by week 7, it gets moved to the next release). Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer IRC meeting, March 13 2011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13.3.2011 18:45, Ton Roosendaal wrote: Hi all, 1) Blender 2.5 project - All signs still positive for 2.57 out of beta release within 2-3 weeks. If we can get the builds released on 30th it'd be great. I'm travelling to Netherlands on 31st of March, and will be back on 6th of April. Probably stop by on 5th at the office. I have the means to do the builds during the time I'm in the Netherlands, but I'd like to have it handled before that if possible. - Meeting confirms we'll need RC builds, preferably a week before official release. - Ton suggests to already make 'official' test builds this week. Having regular builds for testing and as reference for bug reporters is good anyway. Just announce to builders what revision should be built, and I'll have you the Windows builds. - We had some free Visual Studio 2008 licenses in the past. Do more people now need it? Thomas Dinges and Janne Karhu already confirmed they'd love to have one. Ton will try to get a handful free licenses extra. If you can get VS 2010 pro licenses, then I'd like to get one too, so I can ensure official builds work properly with it too - maybe even move to the newer version. - -- Nathan Letwory Blender Foundation | Letwory Interactive http://www.blender.org | http://www.letworyinteractive.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNffH8AAoJEKtfN7KsE0Tt29oH+gKarpDUMAgl30rbxxOgIOY+ qahwvoUQTIi3bIOfcWELBnA00LaAvPqvIahwwY30bM9VdID0TARmnznEERIhhBnL QAzGmU6+rRk2Xn6SGwWGwcxhLG+eDXZ49kgmEaBuY9mR2/HQzzg62mQTD7t3WEqE b1G7CWKWQtrAQACTsATHWJ1LXkMfkx7UZ5IFxOOOaqVba1q9w2I9LNkyCp1ozkg9 cdOHbZGLIeTXanG2QPTo1XM7WxnN6INb7y08sAq5ag/XUcDmSG/eJiQMxFVLhHt4 6LNrI299xbaMZwQ8/rSvDrfcp4bV+a7NUp/rHBM0OWfD9QlUtFLNJy9GugEUZOg= =z171 -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Official Automated Builds
Am 13.03.2011 20:19, schrieb Brecht Van Lommel: Hi all, In the meeting Ton proposed to do official automated builds, that are built and uploaded every day or every few hours. These should effectively be the same as release builds, and could even be used as official releases. This is also a very valuable thing for documenters and authors. No more self compiling for various platforms, never knowing if it works REALLY like in a offcial release. Thanks for this proposal, Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Updated Camera patch
I probably can find a matchmove I did with syntheyes which used a D90 (not fullframe backplate) or do another one if this can help ? I don't know what all this patch can do, me I'm interest of a match Lens value according to the filmgate anyway. F. 2011/3/14 Troy Sobotka troy.sobo...@gmail.com @Mats Holmberg / @Francois T et al: Is there a way we can establish a set of tests to definitively test this patch? Obviously matching a scene to real world units against a test photograph is a possible option here, but I'm wondering if there is something else we can do? Sincerely, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Roadmap for 2.5x - 2.6x - beyond
Big -1 for this, seriously let's not change the naming again! Ton and others decided on naming it 2.57 and 2.58 (Ton sent a mail with this in January to the ML). Let's stick to that! This is the n'th discussion about it on this list, and it starts to get annoying. ;-) Thomas Am 14.03.2011 11:02, schrieb Jonathan Smith: I think this will also make more sense to developers, in that we have 2.60 as the base and we start working up and adding stuff from there, instead of working from 2.58 up to 2.60 and having a bunch of new features in 2.60. Just my two cents, Jonathan ___ 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] Roadmap for 2.5x - 2.6x - beyond
I'm not a coder, but I guess one issue is to determine weather a branch is stable or not, and to know if it have been properly tested. Why don't do this in a more systematic, 'official' way than before: When a branch is getting near completion: 1. Set up a dedicated bug tracker for the branch, provide builds and do an official 'Call for testing' announcement at Blender.org 2. Give it some time, and when the tracker is consider stable enough do the merge In this way you'll get a lot more user involvement and help to identify bugs before a merge to trunk I guess... On Mon, Mar 14, 2011 at 13:47, Thomas Dinges blen...@dingto.org wrote: Big -1 for this, seriously let's not change the naming again! Ton and others decided on naming it 2.57 and 2.58 (Ton sent a mail with this in January to the ML). Let's stick to that! This is the n'th discussion about it on this list, and it starts to get annoying. ;-) Thomas Am 14.03.2011 11:02, schrieb Jonathan Smith: I think this will also make more sense to developers, in that we have 2.60 as the base and we start working up and adding stuff from there, instead of working from 2.58 up to 2.60 and having a bunch of new features in 2.60. Just my two cents, Jonathan ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] OS X update to XCode 4 breaks compiling
Hi OSX devs, Apple's new development update XCode 4 now is available (only when you pay FIVE dollars!). Someone in irc mentioned blender doesn't compile (at all) for it. Further, this XCode revision drops compiling for older OSX versions (10.4 and 10.5) and the install removes all libs/headers for it. Here's a report: http://www.blender.org/forum/viewtopic.php?t=19500 -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Official Automated Builds
Hi, So, I tried out Buildbot anyway, seems to work quite well running it locally: http://users.telenet.be/blendix/buildbot.png Next I'll try to install it on the Blender servers. Probably we'll end up with some volunteers running buildbot slaves on their own systems, and for other platforms we can later try to get remote virtual machines running somewhere. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Official Automated Builds
Hi Brecht, this is really a good idea, I am experienced in using and maintaining different virtualizationproducts in big companies (Virtual box, iESX, KVM, Xen). If you need any advice/help, you can always contact me. Jeroen Bakker On 13-3-2011 20:19, Brecht Van Lommel wrote: Hi all, In the meeting Ton proposed to do official automated builds, that are built and uploaded every day or every few hours. These should effectively be the same as release builds, and could even be used as official releases. To start, some questions for platform maintainers: * Do you have time to set up or help someone else set up such a system for your platform? * Is now a good time to do it, with 2.57 is in 2-3 weeks, or should we do it after? * Are there any pitfalls we should be thinking of? * Do you prefer to run such a system on your own computer or on a server? We can set up a server with virtual machines, for example with virtualbox it should be possible for someone to create the machine locally, upload it, and further maintenance can then be done using a remote login. Alternatively builds could run locally on system from developers or other volunteers. The advantage of having them on a remote server is that it would be easier for multiple developers to fix builds and make releases, but for a single platform maintainer it may be more convenient to just run such a thing locally. We could also start to use a Tinderbox system. Hudson/Jenkins was brought up, Buildbot also seems nice to me. It seems to be quite a bit of work to configure and maintain such a system, so for now I'd like to focus on simply getting automated builds. Thanks, Brecht. ___ 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] Official Automated Builds
Hi, I also have experience with Buildbot. I'll be happy to help if anyone needs an extra hand. Daniel On Mar 14, 2011, at 3:04, Nathan Letwory nat...@letworyinteractive.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14.3.2011 4:22, Brecht Van Lommel wrote: Hi, First let me say, doing the whole continuous integration web service thing is not what I signed up for. It's valuable, but someone else will have to volunteer for that. Mainly my motivation is getting good reference builds for bug reporting, and finding and solving build and installation issues for releases sooner so we can do more efficient releases. So the intention for these builds would be to be identical to release builds. I can hook my release building box to the system, should be no problem. I have had good experiences with buildbot. - -- Nathan Letwory Letwory Interactive | Studio Lumikuu http://www.letworyinteractive.com | http://www.lumikuu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNfegaAAoJEKtfN7KsE0TtzccIALsBfrP1VsTnKjvii9SUiq2O v/yayLm0KJEVzdldtKgRQ2SkdxKE6ukf8D3KfKKmrwfCqnbE+0NVnoxjtFQY3cQo qIVA0w00sJ8SyFvv51v8PH/EPi+9sx7LAnI0CuPJLUWU4frq3fnE3SohlAhbMiV+ Y9PFl/HIFn+WddHnJAUHikPvEXxH6sGbPSuv3kOXbZ2e4BeFB4iEW1q5Tinq27o0 +7bqDhAoxQ3/+6NHf56235WL58oNNfQzjPh72RD3IG7We6dFqYGXaLWhx4LtgxBa pUkds89vsUg2xmlHP0Na2l+CPUTzOoZ662s3CmW89+MAbCfYQXfymCuUhAWXfL0= =WK6G -END PGP SIGNATURE- ___ 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] Official Automated Builds
I have buildbot installed on my FreeBSD 8.2 i386 system. What exactly do I do from here??? On Mon, Mar 14, 2011 at 3:57 PM, Daniel Tavares danielmtava...@gmail.com wrote: Hi, I also have experience with Buildbot. I'll be happy to help if anyone needs an extra hand. Daniel On Mar 14, 2011, at 3:04, Nathan Letwory nat...@letworyinteractive.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14.3.2011 4:22, Brecht Van Lommel wrote: Hi, First let me say, doing the whole continuous integration web service thing is not what I signed up for. It's valuable, but someone else will have to volunteer for that. Mainly my motivation is getting good reference builds for bug reporting, and finding and solving build and installation issues for releases sooner so we can do more efficient releases. So the intention for these builds would be to be identical to release builds. I can hook my release building box to the system, should be no problem. I have had good experiences with buildbot. - -- Nathan Letwory Letwory Interactive | Studio Lumikuu http://www.letworyinteractive.com | http://www.lumikuu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNfegaAAoJEKtfN7KsE0TtzccIALsBfrP1VsTnKjvii9SUiq2O v/yayLm0KJEVzdldtKgRQ2SkdxKE6ukf8D3KfKKmrwfCqnbE+0NVnoxjtFQY3cQo qIVA0w00sJ8SyFvv51v8PH/EPi+9sx7LAnI0CuPJLUWU4frq3fnE3SohlAhbMiV+ Y9PFl/HIFn+WddHnJAUHikPvEXxH6sGbPSuv3kOXbZ2e4BeFB4iEW1q5Tinq27o0 +7bqDhAoxQ3/+6NHf56235WL58oNNfQzjPh72RD3IG7We6dFqYGXaLWhx4LtgxBa pUkds89vsUg2xmlHP0Na2l+CPUTzOoZ662s3CmW89+MAbCfYQXfymCuUhAWXfL0= =WK6G -END PGP SIGNATURE- ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Roadmap for 2.5x - 2.6x - beyond
We've been in some kind of freeze long enough now. Let's have fun for a while, and then try to fix it all up again :) -Ton- Those words are music for my ears :) Congratulations!!! Cheers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Roadmap for 2.5x - 2.6x - beyond
Sorry. I had not realized that this was already set until today. I had figured we would be releasing 2.59 and then 2.60 and then working on new stuff, not finishing with 2.58. If I had known that I would have started protesting earlier. If we want to end with 2.58, then that's fine with me, I was just hoping we could make it more clear to the users that they aren't using beta software anymore, since the last 10 or so releases have all been Alpha and Beta releases. Anyway, If this is the direction that has been decided, go for it. Jonathan On Mon, Mar 14, 2011 at 9:47 PM, Thomas Dinges blen...@dingto.org wrote: Big -1 for this, seriously let's not change the naming again! Ton and others decided on naming it 2.57 and 2.58 (Ton sent a mail with this in January to the ML). Let's stick to that! This is the n'th discussion about it on this list, and it starts to get annoying. ;-) Thomas Am 14.03.2011 11:02, schrieb Jonathan Smith: I think this will also make more sense to developers, in that we have 2.60 as the base and we start working up and adding stuff from there, instead of working from 2.58 up to 2.60 and having a bunch of new features in 2.60. Just my two cents, Jonathan ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Updated Camera patch
Hi, I loaded up my last camera projection scene, taken with an EOS 50D (APS-C sensor). Before, I found the correct hfov using the BLenses script in Blender 2.4x, which I then matched geometry against in 2.5x. But this would give me a focal length based on the default Blender sensor size (32x18), and even if the perspective was right*, the focal length value made no sense, and the workflow was obviously not ideal. * Originally I made the mistake to match against an image that was not lens corrected, so even with location data (measuring the environments length/distances) the geometry shapes and scales became warped... Using a http://lensfun.berlios.de capable app (rawstudio, ufraw, darktable, ...) fixed this. With this updated patch I could select my cameras sensor size and enter the correct focal length used (18mm) and the match was perfect. Mathematically it makes sense, but the great part is that we can use available information (via exif) and not need to convert anything. As for testing, because of the mathematically nature things should just work, but please go ahead and test with your own material! Stuff I haven't tested myself yet, here listed as the modified sources: source/gameengine/VideoTexture/ImageRender.cpp source/gameengine/Ketsji/KX_KetsjiEngine.cpp source/gameengine/Ketsji/KX_Camera.cpp source/gameengine/Ketsji/KX_Camera.h source/gameengine/Rasterizer/RAS_FramingManager.cpp source/gameengine/Rasterizer/RAS_FramingManager.h source/gameengine/Rasterizer/RAS_CameraData.h source/blender/render/intern/source/envmap.c source/blender/editors/sculpt_paint/paint_image.c source/blender/blenlib/intern/uvproject.c - Though I haven't tested it just yet, I'm fairly sure it will work. I just *really* dislike the way we have to subdivide geometry so much, for the projection to stick properly..! Also please test addons that may depend on the camera, as well as importers/exporters (will look at FBX in a bit, but I can't test Collada presently). I wrote an addon that exports a camera in .chan format so I could import it into a Nuke camera, and that works successfully. It still needs some work (import .chan in Blender and maybe import/export geometry) but I will upload it if/when this camera patch becomes default. If you have experience with panorama, please test that as well. Depth of Field should work, but in my attempt to include Distance_Affects_FOV I think the way Blender uses DoF is a little... fishy? If you can think of any other way to test this basic camera, please comment! Thanks! On Mon, Mar 14, 2011 at 12:51 PM, François T. francoistarl...@gmail.com wrote: I probably can find a matchmove I did with syntheyes which used a D90 (not fullframe backplate) or do another one if this can help ? I don't know what all this patch can do, me I'm interest of a match Lens value according to the filmgate anyway. F. 2011/3/14 Troy Sobotka troy.sobo...@gmail.com @Mats Holmberg / @Francois T et al: Is there a way we can establish a set of tests to definitively test this patch? Obviously matching a scene to real world units against a test photograph is a possible option here, but I'm wondering if there is something else we can do? Sincerely, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ 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
[Bf-committers] New wiki page for building on FreeBSD
Hi All, I've written a wiki page for building blender 2.5x on FreeBSD. I just wrote an update to it after verifying that python32 is now correct in the ports tree. The instructions should work on FreeBSD 8.2-RELEASE i386/amd64. Cheers! Peter ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Roadmap for 2.5x - 2.6x - beyond
+1 to brecht's proposal, big +1 to shorter fixed release cycles. -1 for discussions on details of point releases, just go with Ton on this one and focus on real issues :) On Sun, Mar 13, 2011 at 3:08 PM, Ton Roosendaal t...@blender.org wrote: Hi Brecht, I strongly believe we should switch to short, fixed release cycles, and be much more strict in only accepting functionality in trunk that is reviewed and can be stabilized in a short time. Fully agree! :) -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 13 Mar, 2011, at 15:52, Brecht Van Lommel wrote: Hi, I think we should make major modifications to the release cycle, to avoid problems that we've been having with 2.5 and also releases before that. In my opinion a migration schedule for new features as we have done before does not work, because it's unpredictable when developers will be available to work on things, and worse, developers are blocked a long time waiting. There's this dynamic which I think we should try to break: unstable features push back release dates, then after a while, core developers in other areas get impatient and add another unstable feature, which agains pushes things back further, while branches get even bigger and harder to merge. I strongly believe we should switch to short, fixed release cycles, and be much more strict in only accepting functionality in trunk that is reviewed and can be stabilized in a short time. So, this is what I propose we do: RELEASE SCHEDULE Releases are unpredictable, it's not clear when they will happen or when new features can get in. I propose we use a fixed release schedule, to make it more predictable, ensure regular releases, and to encourage good development practices. For example, we could have a 8 week schedule (or even shorter!): weeks 1-3: new features can be merged weeks 4-6: stablizing and enhancing weeks 7-8: critical bugfixes only If a feature is not stable or not documented by week 7, it gets moved to the next release (and preferably we find this out earlier). If you expect a feature is too big to stabilize in the given time, split it up. BRANCHES There is the issue of how to do such a release schedule in terms of branches. Most power users are simply using trunk and not releases, so having separate branches for development and stable releases is not a viable option in my opinion. I propose to center everything around trunk, and let developers use short lived branches while trunk is locked if they want to. If we keep the release cycle sufficiently short, developers know they can merge things soon. I think we should try to avoid branches that live too long. Features don't get good testing, it's demotivating for developers, and merging them destabilizes trunk too much. Just split up things if it doesn't fit the release schedule. Existing major branches should be merged in pieces if they risk destabilizing things too much. If code can't be stabilized in a few weeks, it simply should not go in trunk, in my experience it is always possible to split things up. Brecht. ___ 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 -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New wiki page for building on FreeBSD
Hi again :) Sorry for omitting the URL from the last message, the wiki page is HERE: http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/FreeBSD On Mon, Mar 14, 2011 at 5:31 PM, pete larabell xgl.asyl...@gmail.com wrote: Hi All, I've written a wiki page for building blender 2.5x on FreeBSD. I just wrote an update to it after verifying that python32 is now correct in the ports tree. The instructions should work on FreeBSD 8.2-RELEASE i386/amd64. Cheers! Peter ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Official Automated Builds
Hi, Thanks everyone who's offering help. On the buildbot side, there's two things that may need some attention: * We need build steps to upload builds to the server, keeping the last n builds and removing others. * Adding accounts and build steps must be done by editing the configuration file on the server, which means everything has to go through me or someone else with access. Not sure if there's a good way around it though. On the build system side, we need: * Steps for how to build fully correct releases, which options to use. * Automatic packaging, it seems some work needs to be done here, e.g. make package for cmake is not working for me. For people who want to contribute build slaves: * Wait until we have buildbot running on the server, then I'll give instructions on how to set things up. Thanks, Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Official Automated Builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15.3.2011 2:04, Brecht Van Lommel wrote: * Adding accounts and build steps must be done by editing the configuration file on the server, which means everything has to go through me or someone else with access. Not sure if there's a good way around it though. I can probably be of some assistance in cases where access is needed. On the build system side, we need: * Steps for how to build fully correct releases, which options to use. * Automatic packaging, it seems some work needs to be done here, e.g. make package for cmake is not working for me. As said, I'll be hooking up my release build box for scons/msvc builds. /Nathan - -- Nathan Letwory Blender Foundation | Letwory Interactive http://www.blender.org | http://www.letworyinteractive.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNfsXsAAoJEKtfN7KsE0TtXqcH/0EMi+uoWQCPbDSuDnNUMxZH BacWnLOJNKsnSfMIr7M4oRX6GTR12o8TcIkwAb78N5wdR1/Czfzzu70L8v73AnGG VQZ6HFXEV2ODFr/TUlhQUcVhLRfVOfVT+ZZ8gO6w/iLT1DQ2v5Pa6Ag5NAHEQYFf 7y5qMCAnX65qQdDSxctceu4gKUvKOH1q7/0V4Io8U35DLjZro5jWluSurvnan79N GH2R1H/4xxgoq0l3j9BYuRS8GWwGyvgiSFJEYYh1a+gzl+dF3vtf/8DfykUq22VO L7hR/u8YH5MgP+3kfYz5k4sKN4+jRuSQ3GYnrj5ssBdTe5sGjXc46irUjucm7QY= =yjjF -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Code donation: Dual contouring re-meshing
Hi again, some quick status updates on this: I've started checking out the code, looks like integration as a modifier shouldn't be too hard. As a first step, since the code was written for 32-bit compilation with MSVC, I've been updating it to compile with g++ too, as well as some memory fixes for 64-bit. Current status, I've got it working as a standalone program. Quick test with the Standford bunny, imported resulting .ply model into Blender: http://www.pasteall.org/pic/show.php?id=9959 [on right is original with holes and uneven topology, then middle is rebuilt with a depth-7 octree, and on the left rebuilt with a depth-5 octree.] The output looks good to me, and pretty quick to calculate :) Right now I'm continuing to update the code externally from Blender, making it a bit more cross-platform and reformatting the precalculated text tables into human-readable (i.e. not datatoc'd) C files. Once this is done I'll pull it into Blender intern/, put together a C wrapper, and try it out as a modifier. -Nicholas On Sat, Mar 12, 2011 at 1:25 AM, Nicholas Bishop nicholasbis...@gmail.com wrote: Just FYI, I've started looking at this stuff. Nothing to report yet though :) Anyone else looking at it? -Nicholas On Mon, Mar 7, 2011 at 9:19 AM, Sergey Kurdakov sergey.fo...@gmail.com wrote: Hi All, though I'm not qualified to keep with the donated code, few thoughts,maybe they could be of some use it looks like the approach will be great to be combined with http://www.blendernation.com/2010/11/26/microsoft-kinect-in-blender-realtime-point-cloud-demonstration/ http://www.blendernation.com/2010/11/26/microsoft-kinect-in-blender-realtime-point-cloud-demonstration/kinect like devices get more penetration ( ms will issue sdk and also asus will have their device ) combination of point cloud ( which with more kinects will be very common for designers ) with blender could be a very good point. as for constructive solid geometry there is some code to be used http://www.opencsg.org (a link was mentioned on list few years back btw ) and finally maybe it can be used for fast and accurate booleans something like described here: http://www2.mae.cuhk.edu.hk/~cwang/pubs/TVCGMeshBoolean.pdf Regards Sergey ___ 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] New wiki page for building on FreeBSD
Thanks for the suggestions! I'll make the changes. :) On Mon, Mar 14, 2011 at 7:18 PM, Campbell Barton ideasma...@gmail.com wrote: On Mon, Mar 14, 2011 at 11:25 PM, pete larabell xgl.asyl...@gmail.com wrote: Hi again :) Sorry for omitting the URL from the last message, the wiki page is HERE: http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/FreeBSD On Mon, Mar 14, 2011 at 5:31 PM, pete larabell xgl.asyl...@gmail.com wrote: Hi All, I've written a wiki page for building blender 2.5x on FreeBSD. I just wrote an update to it after verifying that python32 is now correct in the ports tree. The instructions should work on FreeBSD 8.2-RELEASE i386/amd64. Cheers! Peter Good to see FreeBSD build docs :) Some things I noticed while reading... - you had to document applying the glew update, just committed glew 1.5.8 patch, r35550 so this isn't needed. - the build dir is different to the linux docs, its arbitrary but may as well settle on one, how about ~/blender-svn/blender for svn, ~/blender-svn/build for the out of source build? - explanations about threaded make -jN are being duplicated about, we should have a small wiki page for this which can be inlined, not urgent. - On rebuilding calling cmake or ccmake shouldn't be needed since explicitly listing source + headers in CMakeLists.txt, cmake will automatically run if needed, if for some reason BSD needs cmake to configure each time, ccmake ../blender can be replaced with cmake ../blender so the user doesnt have to configure via the UI. -- - Campbell ___ 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
