VTK/Managing the Development Process: Difference between revisions

From KitwarePublic
< VTK
Jump to navigationJump to search
(New page: {{preliminary}} The day-to-day, low-level software development process for VTK has been in place for many years, involving the usual development, dashboard testing, and bug fixing cycle p...)
 
 
(12 intermediate revisions by 4 users not shown)
Line 2: Line 2:


The day-to-day, low-level software development process for VTK has been in place for many years, involving the usual development, dashboard testing, and bug fixing cycle provided by CMake/CTest/CDash. What VTK is missing is more structure around how larger functionality changes are incorporated into VTK. The following describes the process for the high-level (or project level) development of VTK. The goal is to better communicate code changes to the community as they happen, which encourages more community involvement, and document all major functionality changes in VTK.
The day-to-day, low-level software development process for VTK has been in place for many years, involving the usual development, dashboard testing, and bug fixing cycle provided by CMake/CTest/CDash. What VTK is missing is more structure around how larger functionality changes are incorporated into VTK. The following describes the process for the high-level (or project level) development of VTK. The goal is to better communicate code changes to the community as they happen, which encourages more community involvement, and document all major functionality changes in VTK.
A '''project''' in VTK refers to code changes that
* involve several developers over a longer time frame (i.e. weeks or months), OR
* involve the creation of one or more new non-trivial classes, OR
* affect backwards compatibility, OR
* otherwise add, remove, or change a significant piece of functionality to VTK.


==Process Overview==
==Process Overview==


At the start of each project (i.e. any major piece of functionality), groups and individuals with commit access to VTK must first submit development plans to the VTK documentation system, described in a separate document. These submissions will trigger a useful message to the VTK developers list, giving the name of the project and an abstract. This is where discussion of the initial idea may happen by the community, before implementation begins.
# At the start of each project, groups and individuals with commit access to VTK must first submit development plans to the VTK developers list, giving the name of the project and an abstract of the work, along with a link to a publicly accessible development plan (e.g. VTK wiki page) describing the current system in more detail. This is where discussion of the initial idea may happen by the community, ideally before implementation begins.
New projects are monitored by key individuals (VTK topic leads), who will be responsible for tracking various areas of VTK. When necessary, they will solicit the attention of the Architecture Review Board ([[VTK/Architecture Review Board|ARB]]), and may delay significant changes to await ARB approval.
# New projects are monitored by key individuals (VTK topic leads), who will be responsible for tracking various areas of VTK. When necessary, they will solicit the attention of the [[VTK/Architecture Review Board|Architecture Review Board (ARB]]). Significant or heavily disputed changes may await ARB approval.
As development continues, the development plan must transition into a document describing implemented functionality.
# As development continues, the development plan must transition into a document describing implemented functionality.
Individuals who commit code but do not document their plans and implementations will be monitored by the topic leads. They will be warned, and if the behavior continues, their write access may be revoked.
# Individuals who commit code but do not document their plans and implementations will be monitored by the topic leads. They will be warned, and if the behavior continues, their write access may be revoked.


==VTK Topic Leads==
==VTK Topic Leads==


A set of developers chosen by the ARB will act as topic leads for different sections of VTK. Topic leads are responsible for:
A set of developers chosen by the ARB will act as topic leads for different sections of VTK. Topic leads are responsible for:
Tracking code changes in their topic to see that they use appropriate VTK architecture and are well tested.
Tracking new projects related to their topic, and ensuring that appropriate Kitware personnel and/or ARB members are notified of changes.
Before each ARB meeting, topic leads must provide a document to the ARB describing recent development in their area, as well as any plans for new development.


==Tentative Topic Leads==
* Tracking code changes in their topic to see that they use appropriate VTK architecture and are well tested.
* Tracking new projects related to their topic, and ensuring that appropriate Kitware personnel and/or ARB members are notified of changes.
* Before each ARB meeting, topic leads must provide a document to the ARB describing recent development in their area, as well as any plans for new development.


*Pipeline (Filtering subdirectory) - Berk Geveci
{| border="1"
*Base (Common subdirectory) - Berk Geveci
! Topic !! Main Subdirectories !! Topic Lead(s)
*Rendering (Rendering and VolumeRendering subdirectories) - Francois Bertel and Utkarsh Ayachit
|-
*GenericFiltering - David Thompson?
| '''Pipeline''' || /Common/ExecutionModel || Berk Geveci, Dave DeMarle
*Widgets - Karthik Krishnan
|-
*Infovis (Infovis,  Geovis subdirectories) - Jeff Baumes
| '''Standard Data Model''' || /Common/DataModel || Berk Geveci, David Lonie
*Views - Jeff Baumes
|-
*Parallel - Ken Moreland?
| '''Higher Order Elements''' || /Filters/Genericl || Will Schroeder, David Thompson
*Build Process (plus Utilities, Wrapping subdirectories) - Brad King or David Cole?
|-
*Visualization Algorithms - may need further break-down
| '''Rendering''' || /Rendering || Marcus Hanwell, Lisa Avila, Burlen Loring
*Computational Geometry Algorithms - Will Schroeder or Bob O'Bara?
|-
*Imaging Algorithms - Someone from the medical community?
| '''Text Rendering''' || /Rendering/FreeType || David Lonie
*Readers and Writers (IO subdirectory) - Berk Geveci and Utkarsh Ayachit
|-
*GUISupport - Qt - Jeff Baumes?
| '''Interaction''' || /Interaction/Widgets || Will Schroeder
|-
| '''Charts''' || /Charts || Marcus Hanwell
|-
| '''Infovis''' || /Infovis || Jeff Baumes
|-
| '''Geovis''' || /Geovis || Jeff Baumes, Aashish Chaudhary
|-
| '''Chemistry''' || /Domains/Chemistry || Marcus Hanwell, David Lonie
|-
| '''Views''' || /Views || Jeff Baumes
|-
| '''Parallel''' || /Parallel || Ken Moreland, Berk Geveci
|-
| '''Build Process''' || /Utilities, /Wrapping || Brad King, David Cole, Marcus Hanwell, Robert Maynard
|-
| '''Visualization Algorithms''' || /Filters/Geometry || Will Schroeder, Andrew Maclean
|-
| '''Computational Geometry Algorithms''' || /Graphics || Andrew Maclean, Will Schroeder
|-
| '''Imaging Algorithms''' || /Filters/Imaging || Steve Pieper, Bill Lorensen, David Gobbi
|-
| '''Readers and Writers''' || /IO || Berk Geveci, Utkarsh Ayachit, Robert Maynard
|-
| '''Qt''' || /GUISupport/Qt || Jeff Baumes, Clinton Stimpson
|-
| '''Wrapping''' || /Wrapping || David Gobbi
|-
| '''Java''' || /Wrapping/Java || Chris Harris, Sebastien Jourdain
|-
| '''Web''' || /Web || Chris Harris, Sebastien Jourdain
|-
| '''GPGPU and SMP''' || Accelerators || Robert Maynard, Dave DeMarle, Berk Geveci
|-
| '''Testing''' || Testing || Bill Lorensen, Dave DeMarle, Sankhesh Javheri
|}

Latest revision as of 14:51, 11 March 2014

The text on this page is preliminary.
It is subject to change.

The day-to-day, low-level software development process for VTK has been in place for many years, involving the usual development, dashboard testing, and bug fixing cycle provided by CMake/CTest/CDash. What VTK is missing is more structure around how larger functionality changes are incorporated into VTK. The following describes the process for the high-level (or project level) development of VTK. The goal is to better communicate code changes to the community as they happen, which encourages more community involvement, and document all major functionality changes in VTK.

A project in VTK refers to code changes that

  • involve several developers over a longer time frame (i.e. weeks or months), OR
  • involve the creation of one or more new non-trivial classes, OR
  • affect backwards compatibility, OR
  • otherwise add, remove, or change a significant piece of functionality to VTK.

Process Overview

  1. At the start of each project, groups and individuals with commit access to VTK must first submit development plans to the VTK developers list, giving the name of the project and an abstract of the work, along with a link to a publicly accessible development plan (e.g. VTK wiki page) describing the current system in more detail. This is where discussion of the initial idea may happen by the community, ideally before implementation begins.
  2. New projects are monitored by key individuals (VTK topic leads), who will be responsible for tracking various areas of VTK. When necessary, they will solicit the attention of the Architecture Review Board (ARB). Significant or heavily disputed changes may await ARB approval.
  3. As development continues, the development plan must transition into a document describing implemented functionality.
  4. Individuals who commit code but do not document their plans and implementations will be monitored by the topic leads. They will be warned, and if the behavior continues, their write access may be revoked.

VTK Topic Leads

A set of developers chosen by the ARB will act as topic leads for different sections of VTK. Topic leads are responsible for:

  • Tracking code changes in their topic to see that they use appropriate VTK architecture and are well tested.
  • Tracking new projects related to their topic, and ensuring that appropriate Kitware personnel and/or ARB members are notified of changes.
  • Before each ARB meeting, topic leads must provide a document to the ARB describing recent development in their area, as well as any plans for new development.
Topic Main Subdirectories Topic Lead(s)
Pipeline /Common/ExecutionModel Berk Geveci, Dave DeMarle
Standard Data Model /Common/DataModel Berk Geveci, David Lonie
Higher Order Elements /Filters/Genericl Will Schroeder, David Thompson
Rendering /Rendering Marcus Hanwell, Lisa Avila, Burlen Loring
Text Rendering /Rendering/FreeType David Lonie
Interaction /Interaction/Widgets Will Schroeder
Charts /Charts Marcus Hanwell
Infovis /Infovis Jeff Baumes
Geovis /Geovis Jeff Baumes, Aashish Chaudhary
Chemistry /Domains/Chemistry Marcus Hanwell, David Lonie
Views /Views Jeff Baumes
Parallel /Parallel Ken Moreland, Berk Geveci
Build Process /Utilities, /Wrapping Brad King, David Cole, Marcus Hanwell, Robert Maynard
Visualization Algorithms /Filters/Geometry Will Schroeder, Andrew Maclean
Computational Geometry Algorithms /Graphics Andrew Maclean, Will Schroeder
Imaging Algorithms /Filters/Imaging Steve Pieper, Bill Lorensen, David Gobbi
Readers and Writers /IO Berk Geveci, Utkarsh Ayachit, Robert Maynard
Qt /GUISupport/Qt Jeff Baumes, Clinton Stimpson
Wrapping /Wrapping David Gobbi
Java /Wrapping/Java Chris Harris, Sebastien Jourdain
Web /Web Chris Harris, Sebastien Jourdain
GPGPU and SMP Accelerators Robert Maynard, Dave DeMarle, Berk Geveci
Testing Testing Bill Lorensen, Dave DeMarle, Sankhesh Javheri
Retrieved from "https://public.kitware.com/Wiki/index.php?title=VTK/Managing_the_Development_Process&oldid=55206"