ITK Release 4/What Developers Must Do To Contribute to the Users Migration Guide: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
Line 11: | Line 11: | ||
= Proposed Procedures = | = Proposed Procedures = | ||
* Gerrit review checklist | |||
** Step that asks "Does this patch change the API" | |||
** If so, have the changes been documented in the migration guide | |||
** Only accept if documented | |||
* Documentation should include: | |||
** Names of files that change API | |||
** English explanation of changes | |||
** Code example of conversion from old API to new API | |||
* Some parts of documentation could be auto-generated | |||
** Extract English explanation from git commit | |||
** Find conversion examples in diff of tests | |||
** Names of files generated from git commits as well | |||
* Some sort of interface where automatic guesses for each migration component are auto-generated and developer can make changes to auto-generated results. | |||
** Maybe an addition to gerrit (how much gerrit editing can we do?) | |||
** If not, some sort of html form that is auto-populated from git and can be changed manually |
Revision as of 18:22, 7 October 2010
Overview
What Information Must Be Captured
- Git hash of the ITKv4 commit that changed the API
- Migration guide page describing the justification for the change
- Along the lines of:
- Migration Users Guide
- Git hash of the Sequestered Applications commit that fixed the app to build with the new API
Proposed Procedures
- Gerrit review checklist
- Step that asks "Does this patch change the API"
- If so, have the changes been documented in the migration guide
- Only accept if documented
- Documentation should include:
- Names of files that change API
- English explanation of changes
- Code example of conversion from old API to new API
- Some parts of documentation could be auto-generated
- Extract English explanation from git commit
- Find conversion examples in diff of tests
- Names of files generated from git commits as well
- Some sort of interface where automatic guesses for each migration component are auto-generated and developer can make changes to auto-generated results.
- Maybe an addition to gerrit (how much gerrit editing can we do?)
- If not, some sort of html form that is auto-populated from git and can be changed manually