2010-Slicer-Factory - Revision history

Aylward: /* Extensions */

2010-09-15T14:40:08Z

Extensions

Kikinis: /* Extensions */

2010-09-13T18:36:33Z

Extensions

Kikinis: /* Initial Plan */

2010-09-13T18:35:42Z

Initial Plan

Aylward: /* Policies */

2010-09-09T22:15:20Z

Policies

Aylward: /* Initial Plan */

2010-09-09T22:13:34Z

Initial Plan

Pieper: /* Compilers */

2010-09-07T13:50:33Z

Compilers

Kikinis at 12:50, 7 September 2010

2010-09-07T12:50:14Z

Kikinis: /* Introduction */

2010-09-07T12:47:41Z

Introduction

Kikinis at 12:47, 7 September 2010

2010-09-07T12:47:06Z

Kikinis: Created page with '=Introduction= A new compile and debug setup will be created for Slicer OS: Virtual machines for OS X, win 32, win 64, linux 32, linux 64 A variety of compilers Backups =OS …'

2010-09-07T12:45:47Z

Created page with '=Introduction= *A new compile and debug setup will be created for Slicer *OS: Virtual machines for OS X, win 32, win 64, linux 32, linux 64 *A variety of compilers *Backups =OS …'

New page

=Introduction=
*A new compile and debug setup will be created for Slicer
*OS: Virtual machines for OS X, win 32, win 64, linux 32, linux 64
*A variety of compilers
*Backups

=OS available=

=Compilers=

← Older revision		Revision as of 14:40, 15 September 2010
Line 32:		Line 32:

	*We should also have a plan for the extensions and the extension server.		*We should also have a plan for the extensions and the extension server.
		+	* Proposal:
		+	** New e-journal is created to host Slicer modules, data, and tutorials
		+	** Each submission can consist of one or more of the following:
		+	*** Slides, dlls, python code, executables, C++ code, etc.
		+	** MIDAS performs nightly builds and tests appropriate submissions and returns results as dashboards
		+	** Server is indexed by Google Scholar, etc using OAI standards
		+	** Server provides revision control for all uploaded items
		+	** Server allows the author to specify the build environment for the uploaded items
		+	*** e.g., version of Slicer, ITK, ... to be used
		+	** API is provided for querying server from within Slicer
		+	** Slicer modules provide one-click download of tutorials, testing data, etc
		+	** Module testing data is downloaded if a module is tested, as part of the testing process (developers need not search for testing data).

	= Policies =		= Policies =

← Older revision		Revision as of 18:36, 13 September 2010
Line 30:		Line 30:

	=Extensions=		=Extensions=
		+
		+	*We should also have a plan for the extensions and the extension server.

	= Policies =		= Policies =

← Older revision		Revision as of 18:35, 13 September 2010
Line 28:		Line 28:

	I think this is all fairly straightforward -- but it will be a fair amount of work. Hopefully it will be pretty automatic once it is set up, but it will need to be carefully documented and experts will need to be available for troubleshooting.		I think this is all fairly straightforward -- but it will be a fair amount of work. Hopefully it will be pretty automatic once it is set up, but it will need to be carefully documented and experts will need to be available for troubleshooting.
		+
		+	=Extensions=

	= Policies =		= Policies =

@@ Line 31: / Line 31: @@
 = Policies =
-* Limited number of root users
+* Limited number of root users who communicate and record all modifications to the system
 * Dashboard scripts are stored in a repository (svn?) and fetched from that repo every night
-* No machine-specific configurations are done beyond standard package installs as necessary
+* No machine-specific configurations outside of dashboard scripts are done beyond standard package installs
 * Dashboard logins do not have root access
-* Wiki pages are used to track modifications to machines, publicize who is responsible for each ctest script, etc.
+* Wiki pages are used to track modifications to machines, publicize who is responsible for each dashboard script, etc.
-* Machine systems admin is not necessarily the person responsible for any ctest script on the machine
+* Machine systems admin is not necessarily the person responsible for any dashboard script on the machine
-* Ctest script maintainers must subscribe to get emails on dashboard failures for the corresponding project
+* Dashboard script maintainers must subscribe to get emails on all dashboard failures for the corresponding project

← Older revision		Revision as of 22:13, 9 September 2010
Line 28:		Line 28:

	I think this is all fairly straightforward -- but it will be a fair amount of work. Hopefully it will be pretty automatic once it is set up, but it will need to be carefully documented and experts will need to be available for troubleshooting.		I think this is all fairly straightforward -- but it will be a fair amount of work. Hopefully it will be pretty automatic once it is set up, but it will need to be carefully documented and experts will need to be available for troubleshooting.
		+
		+	= Policies =
		+
		+	* Limited number of root users
		+	* Dashboard scripts are stored in a repository (svn?) and fetched from that repo every night
		+	* No machine-specific configurations are done beyond standard package installs as necessary
		+	* Dashboard logins do not have root access
		+	* Wiki pages are used to track modifications to machines, publicize who is responsible for each ctest script, etc.
		+	* Machine systems admin is not necessarily the person responsible for any ctest script on the machine
		+	* Ctest script maintainers must subscribe to get emails on dashboard failures for the corresponding project

← Older revision		Revision as of 13:50, 7 September 2010
Line 15:		Line 15:

	=Compilers=		=Compilers=
		+
		+	= Initial Plan =
		+
		+
		+	(1) get a big mac pro (12 core, 32G, SSD RAID, external backup) and put it on the network at 1249 Boylston, outside the firewall so any of us can access it as factory.slicer.org via ssh and/or apple desktop sharing / vnc. This machine will need to be monitored about weekly for OS patches etc. This host would primarily just be a server for virtual machines, not a workstation per se.
		+
		+	(2) install a vm server (vmware?, parallels? virtual box?) to host all the OS versions we want to build on and test on: mac osx, windows 32 and 64, linux 32 and 64. Exact OS versions to use open to discussion. Each of these virtual machines will need to be monitored about weekly for OS patches, etc.
		+
		+	(3) set up continuous and nightly tests for each part of the NA-MIC Kit on each OS (cmake, vtk, itk, teem, ctk, slicer...). Some will need to be the 'owner' of these test machines to diagnose dashboard issues. We may also want multiple versions of each toolkit. I think if we have a beefy enough mac, we should be able to do all this on one machine but if needed we could have more than one factory machine.
		+
		+	(4) create slicer binary installers for supported platforms and copy them to the appropriate spot on slicer.org for download. Someone will need to be ready to troubleshoot if builds are not available.
		+
		+	I think this is all fairly straightforward -- but it will be a fair amount of work. Hopefully it will be pretty automatic once it is set up, but it will need to be carefully documented and experts will need to be available for troubleshooting.

@@ Line 6: / Line 6: @@
 *A variety of compilers
 *Backups
 =OS available=
 =Compilers=

@@ Line 2: / Line 2: @@
 =Introduction=
-*A new compile and debug setup will be created for Slicer
+*A new compile and debug setup will be created for Slicer under the URL factory.slicer.org
 *OS: Virtual machines for OS X, win 32, win 64, linux 32, linux 64
 *A variety of compilers

← Older revision		Revision as of 12:47, 7 September 2010
Line 1:		Line 1:
		+	Back to [[2010-09-Leadership-Brainstorming\|2010 09 Leadership Brainstorming]]
		+
	=Introduction=		=Introduction=
	*A new compile and debug setup will be created for Slicer		*A new compile and debug setup will be created for Slicer