2011/09/04 Meeting Notes

total log, will be cut down to readable state :)

1 – Current Projects & Code Review Process

point 1: Upload → Contrib

The general consensus is 3 senior bf:extensions devs flag a script, then we ask for the script author to be given svn access & move to contrib.

If we use the project tracker page, we leave a message after reviewing like: +1 for moving, and then give some short remarks about the script itself.
svn access only be given by the bf-extensions admins or bf-committers Currently there is only ideasman42 who is active in this.
mont29 & Crouch & DingTo have agreed to help with this, but not as tracker admins, more like trusted reviewers.
here’s the full list of bf-extensions devs: http://projects.blender.org/project/memberlist.php?group_id=15

point 2: Contrib → Trunk

ideasman42’s suggestion to use http://codereview.appspot.com/ for reviewing scripts was agreed. It’s very good for multiple devs reviewing one piece of code. For small scripts, it’s no big deal, but for larger scripts which intend to be moved into trunk he would like this… To be clear, tracker upload as we do now is ok, this is more a way to review the code and have many devs comment, reply to comments on spesific lines…

We use the same +3 system as for contrib → trunk, but with preferably one admin +1. However, as mindrones and jesterKing are no always available, ideasman42 would be happy to have more devs “allowed” to give final ok… If there are borderline cases, reviewers can mail list and ask… or ask admins!

point 3: Criteria

Don’t accept addons having

Viruses or anything malicious.
Features overlapping with internal features.
Conflicts with internal operators.

Criteria before going to trunk

Meet minimal level of code quality thats acceptable to release and maintainable by others, should the original maintainer be un-available for fixes. TODO, we need to document this still
Wiki page (by release time)
Unittest for imp/exp (by release time)

point 4: Misc

ideasman42 would like a page with basic do’s and don’ts – so when we add new devs they get an idea of whats acceptable. E.g.:

They must join mailing lists http://lists.blender.org/pipermail/bf-python and http://lists.blender.org/pipermail/bf-extensions-cvs .
They should write at least a minimal wiki page.
They can commit to other peoples projects minor fixes.
They can’t commit to other devs’ work heavy changes, unless they have their authorization.

etc.

mindrones noted the current excellent guidelines pages:

mont29 will propose an update of the first page, including those DOs and DON’Ts for new bf-extension devs (mailing list for review).

mindrones notes that the wiki and mailing part is not done properly. He founds himself sending invitations to mailing list all the times and asking for addon wiki page!

NOTE: To do a canned response send out about joining the mailing list.

Undocumented addons will be listed as apart of automated tests that are run before release. One week before release threaten to remove addons with no wikis, and actually do it if they are not added (remove meaning move back to contrib) - ideasman42 look into this.

2 – 2.60 Targets & Scripts to Move & Devs to Grant SVN

meta-androcto asked Crouch, if he could prepare these scripts for 2.6.

motion trail won’t be ready for 2.60.
theme manager may be ready. ideasman42 asked, is this going to be the way to save/load themes? Good question, atm it’s a stable and popular script.
mont29 proposed the sequencer’s select_strips_by_type script for Trunk. However, ideasman42 would rather see this as real Blender C code, so mont29 will recode it and propose a patch!

meta-androcto proposes grant svn access to:

brikbot, has the add_rocks script (wiki page). meta-androcto also asked him to look at adding materials & textures to the masonry script.
revolt_randy, has the add_mesh_beams script.

howardt noted that, as a new author to wiki, it is not totally easy to figure out what you have to do – maybe a step-by-step cookbook for how to add docs for an addon would get new devs over that hump.

NOTE: The 3 Cursor scripts in contrib were flagged at the last meeting. A message was left for the author 2 weeks ago warning that the scripts would be moved to upload until they are repaired (we forgot to mention this but may take action soon).

3 – Review of the Code Review Proccess

Was discussed in 1, see above!

4 – Proposal to ban “import *” from blender scripts (ZanQdo/Campbell)

After some discussion, this was decided:

Ban the “import *” from blender addons. This will be mandatory for trunk scripts, and highly advised for contrib ones.
However, “from foo import bar, blah” is still allowed – in fact, it’s even faster than having to call “foo.bar” (might become important in loops…).

ideasman42 has been maintaining bf-trunk scripts, making sure they don’t “import *”, among other things like pep8…

ideasman42 also advises to use that syntax, when having to import more than a few elements from a module:

from bpy.props import (StringProperty,
                       BoolProperty,
                       IntProperty,
                       FloatProperty,
                       EnumProperty,
                       )

Dev:Py/Meeting/04092011

目次