Scripts that are bundled with Blender release must be working, correct? bf-extensions tracker having a broken category doesn't seem bad, since this is not release. script maintainers then have the responsibility of keeping their own scripts working. API breakage is a temporary problem; once blender reaches release status, I suspect Python api won't be changing for quite some time. I don't see why moving extensions to graphicall really changes anything.
On Wed, 2010-06-16 at 08:10 -0600, Daniel Salazar - 3Developer.com wrote: > 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 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers