Difference between revisions of "Developer Meetings/20160531"
From Slicer Wiki
(Created page with " <br> {{mbox | type = style | text = If you would like to list your topic here, create a wiki account and [{{fullurl:{{FULLPAGENAME}}|action=edit}} edit...") |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 9: | Line 9: | ||
= To Discuss= | = To Discuss= | ||
| − | |||
| + | Topics from Andrey, Steve, and Nicole regarding QIICR use cases that have recently broken: | ||
| + | |||
| + | 1) failure to properly handle multiple dependencies: [http://www.na-mic.org/Bug/view.php?id=4200] - blocker for mpReview users | ||
| + | |||
| + | 2) changes in slicer module imports - [http://slicer-devel.65872.n3.nabble.com/Scripted-modules-using-slicer-module-namespace-need-to-be-updated-td4036768.html] - courtesy email from Andras below: | ||
| + | |||
| + | <pre> | ||
| + | Begin forwarded message: | ||
| + | From: Andras Lasso <lasso@queensu.ca> | ||
| + | Subject: RE: Scripted modules using slicer.module* namespace need to be updated | ||
| + | Date: May 30, 2016 at 5:39:28 PM EDT | ||
| + | To: "'Andriy Fedorov (fedorov@bwh.harvard.edu)'" <fedorov@bwh.harvard.edu> | ||
| + | FYI, these extensions are very likely impacted: | ||
| + | · Reporting | ||
| + | · PETTumorSegmentation | ||
| + | · LongitudinalPETCT | ||
| + | Andras | ||
| + | </pre> | ||
| + | |||
| + | 3) Mitigation of bug tracker spam: | ||
| + | |||
| + | <pre> | ||
| + | Earlier today, a group of highlight motivated spammers manually created account on VTK and CMake issue trackers, and started to manually create 10th of issues with incomprehensible title and contents. | ||
| + | |||
| + | As a proactive measure, I suggest we: | ||
| + | |||
| + | * disable automatic approval of mantis account creation | ||
| + | * allow any user with developer access to approve account request | ||
| + | |||
| + | Let me know if that sound reasonable and I will share this plan with the Slicer developer list, | ||
| + | </pre> | ||
= Updates = | = Updates = | ||
| + | * Discussed progress at the hackfest. Considered the pure javascript dicom io and related interoperability projects. | ||
= Conclusion = | = Conclusion = | ||
| + | |||
| + | * Jc will look at issue #1 this afternoon. | ||
| + | |||
| + | * Issue #2 is related to startup time optimization. The slicer.module* style of access meant that there was a duplication of entry points and that meant extra overhead and slower performance. | ||
Latest revision as of 18:10, 31 May 2016
Home < Developer Meetings < 20160531
 |
If you would like to list your topic here, create a wiki account and edit this page. |
To Discuss
Topics from Andrey, Steve, and Nicole regarding QIICR use cases that have recently broken:
1) failure to properly handle multiple dependencies: [1] - blocker for mpReview users
2) changes in slicer module imports - [2] - courtesy email from Andras below:
Begin forwarded message: From: Andras Lasso <lasso@queensu.ca> Subject: RE: Scripted modules using slicer.module* namespace need to be updated Date: May 30, 2016 at 5:39:28 PM EDT To: "'Andriy Fedorov (fedorov@bwh.harvard.edu)'" <fedorov@bwh.harvard.edu> FYI, these extensions are very likely impacted: · Reporting · PETTumorSegmentation · LongitudinalPETCT Andras
3) Mitigation of bug tracker spam:
Earlier today, a group of highlight motivated spammers manually created account on VTK and CMake issue trackers, and started to manually create 10th of issues with incomprehensible title and contents. As a proactive measure, I suggest we: * disable automatic approval of mantis account creation * allow any user with developer access to approve account request Let me know if that sound reasonable and I will share this plan with the Slicer developer list,
Updates
- Discussed progress at the hackfest. Considered the pure javascript dicom io and related interoperability projects.
Conclusion
- Jc will look at issue #1 this afternoon.
- Issue #2 is related to startup time optimization. The slicer.module* style of access meant that there was a duplication of entry points and that meant extra overhead and slower performance.
