Developer Meetings/20121204

To discuss

• Slicer 4.2.2 status
• Mailing questions
  • NiftyReg and Slicer4
• Code associated with download.slicer.org (see below)
• Mantis workflow (see below)

Conclusion

• Nicole and Steve will be looking at issue 1690
• Change number of extensions displayed on the catalog
• Nicole will submit an issue illustrating with more details the problem associated with MRB.
  • In order to have a stable release preventing the user from getting in "unwanted" state: What about disabling SceneView in the release ? Or MRB? Gather feedback from the community doing a survermonkey ?
• Alex reported issue related to QVTKWidget + cache update. See http://www.na-mic.org/Bug/view.php?id=2815
  • The idea would be to reproduce the issue using VTK6 and discuss with Clint Simpson (maintainer of QVTKWidget)
• Alex> Will look at the problem with saving/restoring camera position: http://www.na-mic.org/Bug/view.php?id=2758
• Jc> Retrieve the details regarding NiftyReg and Slicer4.
• Discussed performance tests
  • Julien will try to find baseline performance tests for comparison while we optimize
  • Nicole has annotation test already in ctest
  • discussion of current bottlenecks: vtkFixedPointRayCastMapper gradient table, QVTKReconnnect, vtkEventBroker::GetObservations, qMRMLSceneModel
  • There will be a breakout at project week to discuss performance profiling tools (Instruments on mac)

Additional material

Code associated with download.slicer.org

// ------------------
JC,

please check the selections for the pull down menus on the left side of the page. Please note that they are not affecting the URL.

slicer.kitware.com is the source, download.slicer.org/stats is the official face. I asked Mike to change the appearance of the circles. I did not like the bio hazard signs.

Ron

// --------------
Hi Ron, 

Given the fact the page you mentioned [1] has been developed by Mike and also considering that the source code is not publicly available, we can't update it, test it or provide patches.

May be we should think about unifying effort and avoid redundant work ?

Thanks
Jc

[1] http://download.slicer.org/stats

// --------------
JC,
A good topic for the hangout. Unfortunately, I am not going to be joining next few weeks.

Ron

Mantis workflow discussion

Hi Folks, 

To bring light in our mantis workflow and clarify the terms "Assigned", "Acknowledged", "Confirmed", "Resolved", "Closed", I invite you to look at the following page:

See IssueWorkflow

As a developer, an issue is assigned to you, then you can eventually ask for feedback.  If the work to be done is understood, you then acknowledge the issue. It is only when you start to work on an issue that you confirm it. When the work is completed, you resolve it. The reporter will then close it.

Note also that the IssueWorkflow page as been referenced from the pages: Report a problem, Create a feature request , ContributePatch, Developers/StartHere.

Let me know if you have any question, 

Thanks

Hi JC,

I think that's too complicated, we want to encourage users and
developers to use Mantis to report and fix bugs and this adds even more
steps to the process. The Mantis interface has so many options that it's
already hard to use and I'd prefer a move to simplification rather than
complication.

I'd propose taking the confirmed/acknowledge steps out and replacing
them with posting notes:
As a developer, an issue is *assigned* to you.
The developer optionally asks for *feedback*, the bug reporter responds
to the feedback request, and either the reporter or developer resets the
issue to *assigned*.
The developer posts notes to the bug page as it's being worked on.
Once the work is completed, the developer *resolves* it.
The reporter will then *close* it or *reopen* it with a note.


How do other developers feel? Can we discuss this during the hangout today?

Nicole

Hello fellow Slicer developers,

I agree with Nicole on having a simple and succinct workflow since Mantis is the only collaboration/update/status tool for Slicer developers.

I propose having names that are intuitive:
"New"/"Backlog" for when a new bug is reported. No need for "assigned" as it gets assigned immediately.
"Active Development" for when the developer starts working on it.
"QA/Review/Testing" - the developer updates the bug to this status when he is done working on it and would like fellow developers to review/test it. This can be optional based on the priority and triviality of the issue.
"Resolved/Customer-QA" - When developers are satisfied
"Closed/Re-open" for the reporter/customer to evaluate the solution.

Sankhesh