利用者:Mindrones/Wiki/Proposals/2009/Workflow/Develop

提供: wiki
移動先: 案内検索

Using wiki for development


Feature requests


  • Feature requests from users
  • Feature a developer wants to develop
  • Companies paying a developer for features they need

Feature requests Tracker

  • Feature requests tracker (possibly pubblic)
  • Folders with Manual structure
  • Ubuntu uses a blueprint system for handling

specifications for new features


Discussion


  • Discussion on wiki
  • Discussion on blenderartists
  • Discussion on IRC

Coding and committing


Then the developer:

  • make a unique patch, post it in the tracker and ask other developers/users to revision, and some day his patch goes into trunk, OR
  • open an svn branch and start committing patches to svn, and some day his branch is merged to trunk
  • in any case he could explain ideas and functionalities in func-board mailing list, in the patch tracker itself, or wiki

Testing / discussion


People compile and try the patch/svn-version and give some feedback in wiki, chat, trackers, or mailing lists

svn log commits tags


At this point we can have one (in case of a patch) or more commits in svn, but release might happen way after this commit.
How to remember this has happened? As for now we have svn log, which has to be read and catalogued "by hand".
Proposal: devs put a newline in their committ like:

WIKI: mesh, undo

and this can be parsed to add a special page in wiki with all the svn logs that contain those TAGS. In case we want to see pages related to more than 1 word, we can use the DynamicPageList alredy installed on Blender wiki.

See this section about categories and tags in wiki.

<bebraw>I thought about the commit tagging problem (how to know which tags to use
in the first place). There probably has to be some
page that lists all the available tags. This way people actually know
which tags they can use. Even better there could be a specific
application that would make tagging easier (the app would just help to
compose the commit message and help enforce commit rules (header,
message content, tags etc.)). As people make mistakes (forget to tag,
use wrong tag, etc.) there should be some way to modify the tag
information related to commits later (this is probably a system
separate from commit log one and is then combined to the original
commits somehow?).

The next section might offer a good answer to these thoughts?

Blogging via mail

Some blogging or photo sharing sites let you post blogs (and tag them) via mail:

Since Apricot's blog uses Wordpress, which has an xmlrpc interface, it lets you blog via mail! :) Using the same (already known) software, we could setup a blog just for publishing svn logs and we would have a ready-made system for let users manage tags :)
It would be a matter of set svn to send mails to blog mail (together with usual mails to bf-blender-cvs list).
Then with a python script we could retrieve the tags and periodically update a wiki "svnlog" page (with Categories as chapters and tags as sub-chapters), or many svnlog pages divided per categories and tags. See this reference.

Discussion