[Bf-committers] Blender Foundation Development Team report week 37

[Nathan Letwory]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Yet another week gone by and lots of work done. Warning, lengthy post,
actual update until dashed line, after that bug reporting talk.

Janne has been busy with particle and physics bugs, fixig 7 of them by
friday. Janne is now studying smoke code, so he should be able to start
fixing bugs related to that soon enough. Janne has done a tentative fix
in SIMD SVBHV ratrayce code, it'd be great if people could test this.
The revision that has the fix is r31984, so any revision after that
should have problems related to that code fixed (see for instance
https://projects.blender.org/tracker/?func=detail&aid=23562&group_id=9&atid=498).

Campbell added PNG export to UV layout, cleaned up addons (registration,
unregistration, error reporting, etc). He also made the keyconfig system
into a preset system, along with some bug fixes for that. Campbell fixed
loading images larger than 2GB (filesize). And a new operator function
check() got introduced, allowing for nice feedback features like in
filebrowser: http://dl.dropbox.com/u/1769373/rt/check_feedback.png (in
this case tells you that an existing file as about to be overwritten in
a clear way).

I have been busy also on bugfixing. Worked on fullscreen support
together with Dalai Felinto. I fixed assinging of the windows key (super
key) on Windows and Linux. I also applied a number of patches from our
patch tracker fixing various bugs (thanks to all the patch writers!).
For diagrams and numbers you can visit
http://www.letworyinteractive.com/b/2010/09/blender-foundation-status-update-week-37/

Diego has been busy and will be busy with studio work until end of October.

- ----------

And before I forget, I wrote a little about our bug handling process on
my blog, I'll replicate the text here for those who don't like to click
on links ;)

"
People have been asking me how we handle bug reports. For Blender 2.5x
series we use the Blender 2.5 Bug Tracker (which is still behind log in)
with bugs set to data type Blender 2.5 Bug Tracker.

In our tracker we have the following states for Resolution: None, New,
Investigate, Ready (rare, prestage for Fixed), Approved, Rejected,
Postponed (unused), Fixed, Duplicate and Todo.

When a new report is submitted the report is None, sometimes the user
sets to New, either way is OK. The next step is for a dedicated
developer to do a first assessment of the report. The idea of the
triaging is that the developer tries to determine if it’s a valid report
and if so, assign it to a developer who can handle the bug (code owner,
module owner). The bug will be assigned and set to New, or if the
triaging developer is certain, Approved. If a report is not valid, the
report is marked Rejected and State is set to Closed. An invalid report
is often:

    * misunderstanding of how a feature works
    * a user not aware of some feature
    * something that didn’t work like a user expected, but was designed
or implemented in that way

Either the triaging or assigned developer can set Resolution to
Investigate, although this is not often used by all developers. I like
to put it on Investigate to signal the reporter and interested parties
that the issue is being looked at. When a bug is fixed the assignee sets
Resolution to Fixed and State to Closed. This we do mostly on basis of
testing by developer, who might or might not have asked other developers
to test. This depends on the complexity of the issue. Only if the
reporter notices that an issue hasn’t been fixed properly is a Fixed and
Closed report reopened.

If similar reports have been reported before it is marked as Duplicated
and set their State to Closed. We try to put in comments of both the
duplicate and original bug links to the other report, so all can be
verified when a fix is found.

To help us manage the influx of bugs we’ve decided to keep in the bug
tracker only reports that are actual bugs to our standards. A bug is
something that is intended (code and design) to work, but doesn’t.

Reports can be marked also as Todo and moved to the todo wiki. In that
case reports are closed too. Reports eligable for move are often related
to features that haven’t been fully implemented (or at all). Also
reports of recurring issues that we have trouble finding good solutions
for in a short timespan can be moved to this todo page. An example is
several OpenGL problems that can happen on some cards, but also some
larger tasks that can take some time and need someone to sit down and
actually do it. The todo list is for both old developers and for those
who want to start working on Blender code. The bug tracker is a good
place, of course, but our todo page will contain sections that can have
links to the bug tracker, and are thus easier to oversee for developers.
Right now the todo list is in many places just bunch of bullet lists,
but I intend to write out more details for as many sections as possible
in the coming time as part of my role for Development Support, along
with coder documentation on what to do, how, where, etc.

The rules are not enforced, but it would be benificial if both users and
developers followed the rules as much as possible. It’ll help me and
others in handling the bugs and quickly respond to changes and new ones.
"

So, that's it for now.

/Nathan

- -- 
Nathan Letwory
Blender Foundation | Letwory Interactive
http://www.blender.org | http://www.letworyinteractive.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMlp90AAoJEKtfN7KsE0Tt4OgIAIm5n4l+ms7mrELhUQqCtLLX
pYDxFCWm/3sO/tSckWbAUXbYozYYF9RsqeZAkpONjHxzqtyfNuRY5mfiMEhi7E4o
MS0HjPwkODXo9WMBZbzhcqUJO+zXhgfr3uc7ZH8jq+izo1hu7eMmA+L08+91y2ji
8C0CYJOW76urQhLSjCVLpfQOIDTrIb2GFCLqgGOUlTuBni1vbAwzDdkowEkLtQNZ
8n1g3+Edxi4EMMIwJGWR5b0iKRCerRM3+EiMDyKdySykCpraC7RDkVwzhe4BWk63
48mowbbsmaBQJj53zGSVd6NMd73H6errikGtvSlK1jLoy8LnFEy3Ux04nC2oAPo=
=qBqX
-----END PGP SIGNATURE-----