Difference between revisions of "Developer Meetings/20160531"

From Slicer Wiki
Jump to: navigation, search
 
(2 intermediate revisions by 2 users not shown)
Line 27: Line 27:
 
·        LongitudinalPETCT
 
·        LongitudinalPETCT
 
Andras
 
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>
 
</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



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.