[Bf-python] BlenderPython Sunday Meeting Report

[Jonathan Smith]

On Mon, Aug 8, 2011 at 5:43 PM, Campbell Barton <ideasman42 at gmail.com>wrote:

> On Mon, Aug 8, 2011 at 3:37 AM, Daniel Salazar - 3Developer.com
> <zanqdo at gmail.com> wrote:
> > Criteria not to accept scripts:
> >
> > - viruses, etc.
> > - features overlapping with internal features
> > - conflicts with internal operators
> +1

Also +1


> > Criteria before going to trunk:
> >
> > - pep8 compliant
> > - wiki page
> > - unittest for imp/exp
> +1 in principle that we _should_ do thsi but not sure if this is
> making our requirements too hight - we may loose contributors from
> this?
>
> Perhaps the requirement can be that these are done before next release
> or removal?, not sure how best to ensure this.

+1 for requiring the cleanup to be done before the next release, but not
needing it to be done before being added to trunk. I can see lots of
benefits for this, however if it happened, we would have to make sure we
weren't lax about enforcing it (eg. Removing it from trunk if the
requirements were not met, most importantly the wiki page and unittest
requirements)


> > Scripts currently failing to load in SVN:
> >
> > Cursor Control
> > Cursor History
> > Cursor Memory
> > API Navigator
> >
> > Scripts that fail to work in SVN:
> >
> > Reload Text Datablock if Modified
> ^, seems like something that should be built into blender or not at all.
>
> > Other Notes:
> >
> > IvyGen, move to Toolbar (not 3D view / Add / Curve), truman will do
> tomorrow
> >
> > hotkeys seem to work much better now, kudos to brecht
> >
> > Steps to take next month:
> >
> > - Proposal to add a "Under Maintenance" flag for scripts that break
> > due to API changes. Avoids unnecessary moving out of trunk while
> > visually communicating the broken status by graying them out or
> > changing color in the addons list
> +1, moving scripts back and fourth is no fun. perhaps could hide these
> on release builds?

 I am no expert at the way tagging for a release works, but wouldn't it be
possible to just not tag the scripts which are broken? Maybe we could
include a small file with the names of each script which is in the "Under
maintenance" category, or automatically seach each script to see whether or
not the "Under Maintenance" flag has been called, so that at every release
the proper scripts are left out.
However I also like the idea of "visually communicating the broken status",
although we do have the "!" icon, that is used for a lot more than just
saying a script is broken. Maybe changing the colour of the script (to
something like red) in the addons list would be the best way to go. That way
the script can still be turned on (if you want to test it), but it serves as
a warning for people using the latest builds that the script might not work.
We could also add a line in the description automatically which would
explain that the script is "Under Maintenance".

> - Create a post at BA to call for files used in an imp/exp test bed.
> > Also ask for a user to document rigify and ask for impressive examples
> > of script usages for documentation.
> Great! this would help a lot, I can assist with working out what
> examples are needed for each formats, since I have setup ctest for
> quite a few already, would also like to be involved with the initial
> request on BA- could draft be posted on this list or a wiki link? -
> there are some requirements Id like to suggest.
>
> > - Proposal to split Import/Export category in two
> -1, internally can see why this might make sense in some cases but
> from user POV I think this is just annoying and too fine grained
> control.

> Next Meeting: Sept 4
> >
> > cheers!
> > Zan
>
>
> --
> - Campbell
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python
>

Cheers,
Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20110809/d0f1cf43/attachment.html>