[Bf-python] Py Dev Monthly Meeting #2 Logs

[Bastien Montagne]

Hi,

Le 2011/09/05, Brendon Murphy <meta.androcto1 at gmail.com> à écrit :
> =2011/09/04 Py addonsDev Meeting Notes=
>
> ==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-pythonand
> 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:
> *http://wiki.blender.org/index.php/Dev:Py/Sharing
> *http://wiki.blender.org/index.php/Dev:Py/Sharing/Upload
> *http://wiki.blender.org/index.php/Dev:Py/Sharing/Contrib
> *http://wiki.blender.org/index.php/Dev:Py/Sharing/Release
>
> mont29 will propose an update of the first page, including those DOs
> and DON’Ts for new bf-extension devs (mailing list for review).

Here is the first proposal about that topic: 
http://wiki.blender.org/index.php/User:Mont29/Addons/Temp/Dev:Py/Sharing

That ain’t much (I’m sure I forgot some important points…), so don’t 
hesitate to comment it, or even edit it directly if you have wiki write 
access!

> 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.
> *[http://projects.blender.org/tracker/index.php?func=detail&aid=26374
> motion trail] won’t be ready for 2.60.
> *[http://projects.blender.org/tracker/index.php?func=detail&aid=26659
> 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 [
> http://projects.blender.org/tracker/index.php?func=detail&aid=25833
> 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
> [http://projects.blender.org/tracker/index.php?func=detail&aid=27314&group_id=153&atid=467
> add_rocks] script
> ([http://wiki.blender.org/index.php/Extensions:2.5/Py/Scripts/Add_Mesh/Rock_Generatorwiki
> page]). meta-androcto also asked him to look at adding materials &
> textures to the masonry script. *revolt_randy, has the [
> http://projects.blender.org/tracker/index.php?func=detail&aid=26911&group_id=153&atid=467add_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: <pre>from bpy.props import
> (StringProperty, BoolProperty, IntProperty, FloatProperty,
> EnumProperty, )</pre> Meeting Closed -------------- next part
> -------------- An HTML attachment was scrubbed... URL:
> http://lists.blender.org/pipermail/bf-python/attachments/20110905/be730e1d/attachment.htm

Cheers,
Bastien.