Developer Meetings/20121127
From Slicer Wiki
Home < Developer Meetings < 20121127
Contents
To discuss
- Slicer 4.2.2 planning - Currently targeted for Dec 1st
- Code associated with download.slicer.org (see below)
- http://www.na-mic.org/Bug/view.php?id=2608
- Mantis workflow (see below)
Conclusion
- Discussed issue #2785
- Model Displayable manager test has leaks
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