One important thing to consider is the needed ability to separate Blender release cycles and addons update cycles, we propose a third-party addon repository hosted at graphicall because of that reason. Script maintainers could push updates without the need for people to download a new blender version. This is specially important for people who do not use unofficial builds
cheers Daniel Salazar www.3developer.com On Wed, Jun 16, 2010 at 8:02 AM, mindrones <mindro...@gmail.com> wrote: > Hello, > > sorry for the long mail, there is some stuff that came up in irc that > I'd like we discuss here. > > Introduction > ===================================================== > > There has been some discussion in #blenderpython about what to do with > "broken" scripts in bf-extensions svn: basically someone isn't > comfortable including scripts in the category "Broken". > > There's been some argument about the fact that people use Graphicall > builds with scripts bundled in, and this has been my exact proposition > when I first proposed bf-extensions workflow (tracker -> svn contrib -> > svn trunk). > I believe that having Graphicall distributing builds with embedded > contrib scripts is cool because people can test and report (and BTW, > Dingto added a "Report Bug" button to the addons panel so now it should > be easy to have feedback from users). > > But, there is some feeling that for this same reason we should provide > un-broken scripts. I don't think so. Graphicall is cool, but if it takes > scripts from bf-extensions it depends on the work being done in > bf-extensions, not the opposite. > > I don't think that we can maintain bf-extensions as it was a Release > each given day :) > > It might happen that an API change breaks a scripts or two and Campbell > already fixes scripts when he changes the API, but he confirms he > usually doesn't check contrib so some script might slip, it happens. > > Also, script developers can disappear at any time, even if their script > is in trunk. So if a script remains unmaintained for a long time we > should remove it, if it stays there broken for a reasonable time (means > days or a couple of weeks) IMO it can stay. It is also a good motivation > to fix it. > > Meta-Androcto also talked about "moving contrib scripts in Graphicall" > (which isn't very clear statement indeed) but I don't think this is > desirable, especially if the development will happen outside of a public > svn. > > > I propose here 2 solutions for 2 problems: > - how to solve broken scripts stuff > - how to have contrib scripts in blender > > > BROKEN SCRIPTS PROBLEM > ===================================================== > > Two usual cases: > > A) We enable the addon (we don't install it) > > To do this in the bl_addon_info dict we can add a "status" key that > could be = 'WORKING' or 'BROKEN' > > Based on that, we do somthing similar to this mockup: > http://www.pasteall.org/pic/show.php?id=4003 > Like this, when we enable an addon it is evident it is broken. > > > B) We install the script so that next times it is already enabled. > > If after a commit an installed script becomes broken, again we could > use the "status" key in the bl_addon_info dict to: > - disable the script (unregistering it?), and > - alert the user with a popup > > If this approach is ok, we could even think about put this info in the > startup panel, but it's not important now. > > > CONTRIB SCRIPTS PROBLEM > ===================================================== > > Currently this folder > https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/addons/ > is fetched into blender/release/scripts/addons. > > We can do the same for contrib: this folder > https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons/ > could be fetched into a subfolder of blender/release/scripts/addons, > like blender/release/scripts/addons/contrib > > This are source folders, not officially released folders. > > So if in Scons/CMake we could put a new variable like > WITH_CONTRIB_INSTALL:BOOL = OFF (cmake) > or > WITH_CONTRIB_INSTALL = 'false' (scons) > > and this would mean that we DON'T copy scripts from > blender/release/scripts/addons/contrib in the usual > ./blender/scripts/addons or not > > If we know this and wanto to do it, we set up > WITH_CONTRIB_INSTALL:BOOL = ON (cmake) > or > WITH_CONTRIB_INSTALL = 'true' (scons) > to include contrib scripts into out build. > > Like this, one has to know what he's doing to enable contrib scripts, it > cannot happen by default, and this applies also to Graphicall builds. > > ===================================================== > > > Suggestion are more than welcome! :) > > PS: we're not discussing py security issues here, please dont use this > thread to start again discussing about sandboxing and blabla, thanks. > > Regards, > Luca > > _____________________________ > > http://www.mindrones.com > _______________________________________________ > 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