They are specified properly in an appropriate branch/tag.
If we do 'a' release it totally happens in the tag now and we only backport
there crucial fixes.
It's arguable, but don't really think doing 'a' release in a tag would make
master branch having 'a' character as well. It's just two
In my experience non techy people will happily ignore the little
warning we have (happens over and over to my clients and coworkers). I
propose making a blocking popup like this:
This file contains drivers and python scripts that have been disabled
for security reasons.
* Continue with disabled
Rather than trying to sandbox python or limit functionality, why not just
sandbox the environment blender is running in? One could set up a render
server which clones a previously set up user with all the necessary
software installed in the user's path and setroot it so it can't touch
anything
That sounds like a VM to me?
Daniel Salazar
patazstudio.com
On Thu, Jun 5, 2014 at 1:07 AM, Dahlia Trimble dahliatrim...@gmail.com wrote:
Rather than trying to sandbox python or limit functionality, why not just
sandbox the environment blender is running in? One could set up a render
server
Yes, that would be one way to do it. Perhaps a render appliance.
On Thu, Jun 5, 2014 at 12:29 AM, Daniel Salazar - patazstudio.com
zan...@gmail.com wrote:
That sounds like a VM to me?
Daniel Salazar
patazstudio.com
On Thu, Jun 5, 2014 at 1:07 AM, Dahlia Trimble dahliatrim...@gmail.com
If we consider the tag and git master as two different projects,
we should've bumped BLENDER_VERSION to 271 or made another macro like
BLENDER_RELEASECYCLE_VERSION=271 to indicate the git master actually
became 2.71-alpha when starting the new release cycle. Currently,
there is no infallible way
Downtime and reboots incoming:
http://www.freebsd.org/security/advisories/FreeBSD-SA-14:14.openssl.asc
Also, aware of wiki lighttpd constant crashing. Tried some more tweaks,
sorry for the restarts.
Dan
___
Bf-committers mailing list
