Change Details

To ensure a good experience for developers or advanced users and to keep the work for the core team on a manageable scale, it is important to know what guarantees are given for different parts of the MITK Git repository. This allows - developers to make a qualified decision if they want to play it safe, go bleeding edge (and we mean bleeding, so don’t cry if you get cut ;) or something in between. - contributors (internal and external) what the definitions of done (DODs) are for contribution. The code guarantees are grouped in quality levels (Q0-Q3) which are used to easily reference/communicate quality promises and requirements in our release concept. ==Quality levels In the following we explain the different quality levels, their intended purpose and their given guarantees / quality measures. This helps developers and power users to pick the right starting point for their own builds or developments. Quality levels always have a repository scope. Meaning, that a branch/tag in the repository always has one specified quality level (e.g. origin/develop is Q1). The guarantees given in a quality level may only hold for a part of the source tree (e.g. in origin/develop the whole source tree compiles, but only a part of the source tree gets active code review). That's why quality guarantees have a source scope; if no source scope is specified, one can assume a global scope for this guarantee. ===Q0 - Work In Progress (WIP) level Nearly no guarantees at all! This is ongoing work in progress. You should *only* base your own work on or build this quality level if you really know what you are doing (e.g. you have talked to the branch owner and his given guarantees are sufficient, you are working on a closely related topic, etc.. Developers are requested to ensure that all commits can be compiled, but even this is not an obligatory thing; not even for our tier 1 platforms. So, be welcomed to the wild west and don’t say we haven’t warned you! Yee Haw... **Guarantees:** - Branches are associated with a task, to follow the process and its history (even if the branch is merged and gone). Therefore all branch names obey the naming schema that encodes the task number: `T<tasknumber>-<human_readable_title>` **Where:** feature/bugfix branches, hotfix branches, support branches ===Q1 - CI level (aka Nightly level) The compilable, CI monitored, bleeding edge; no more, no less. You can be sure that it compiles, that the CI checked the unit tests and that experienced developers reviewed changes to the critical or important parts of the code base. But that’s practically it. **Guarantees:** - All guarantees of Q0 - Code compiles on all [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 1 platforms]]. - Nightly unit tests. Green test state will be assured for all [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 1 platforms]]. If Dashboard is not green on tier 1 for any reason, it will be promptly fixed. - Comits are reviewed by MITK developer. The review ensures that all process guarantees (code compiles, unit tests…) are fulfilled and comprises a code review - Source scope: the source parts specified here - https://phabricator.mitk.org/owners/package/1/ - https://phabricator.mitk.org/owners/package/3/ **Where:** origin/develop, release branches ===Q2 - Beta level For developers that are not depending on the UI/Qt parts of MITK, it is the save pick as green dashboard (unit tests) is guaranteed. All who want to use the Workbench or a like should be aware, that undetected errors in the UI might have slipped in as only fundamental smoke tests have been made and extensive UI checklist testing is *not* guaranteed at this level. So if you make UI developments, it is a good practice to first check the UI parts relevant for you, before starting your own developments. Otherwise it becomes hard for you to distinct, if problems that occur are introduced by your new changes or where already present at your starting commit. **Guarantees:** - All guarantees of Q1 - Commit are reflected in changelog. - Code compiles also on all [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 2 platforms]]. - Passed simple smoke tests for all [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 1 platforms]] - Installers are generated and install - Application starts and closes properly **Where:** origin/master ===Q3 - Production level Recommended for usage if you want the highest quality. e.g. for a production environment. But as a trade of, it does not provide the latest features, additions and improvements. **Guarantees: ** - All guarantees of Q2 - Passed checklist testing - Source scope: TBD - Documentation is up to date - Source scope: modules and plugins specified in here - https://phabricator.mitk.org/owners/package/1/ - https://phabricator.mitk.org/owners/package/3/ - All associated web resources are uptodate and official release installers are available on [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 1 platforms]] **Where:** commits in origin/master tagged as public releases

To ensure a good experience for developers or advanced users and to keep the work for the core team on a manageable scale, it is important to know what guarantees are given for different parts of the MITK Git repository. This allows... - developers to make a qualified decision if they want to play it safe, go bleeding edge (and we mean bleeding, so you may get cut) or something in between. - contributors (internal and external) to understand the definitions of done (DODs) for contributions. The code guarantees are grouped into quality levels (Q0-Q3) which are used to easily reference and communicate quality promises and requirements in our release concept. == Quality levels == In the following we explain the different quality levels, their intended purpose, given guarantees and quality measures. This helps developers and power users to pick the right starting point for their own builds or developments. Quality levels have a repository scope. A branch/tag in the repository always has a certain quality level (e.g. //origin/develop// is Q1). The guarantees given in a quality level may only hold for a part of the source tree (e.g. in //origin/develop// the whole source tree compiles, but only a part of the source tree gets active code reviews). That's why quality guarantees have a source scope; if no source scope is specified, the global scope is implied. === Q0 - Work In progress (WIP) level === Nearly no guarantees at all! This is ongoing work in progress. You should only build or base your own work on this quality level if you really know what you are doing (e.g. you have talked to the branch owner and his given guarantees are sufficient or you are working on a closely related topic). Developers are requested to create compilable commits, but even this is not obligatory. So, be welcomed to the wild west and don’t say we haven’t warned you! Yee haw... ===== Guarantees ===== - Branches are always associated with a task, to follow the process and its history (even if the branch is merged and gone). Therefore, all branch names obey our naming convention that includes the corresponding task number. For details, see [[mitk/dev/git-branching]]. ===== Where ===== - feature and bugfix branches - hotfix branches - support branches === Q1 - Continuous integration (CI) level === The certainly compilable, CI-monitored, bleeding edge; no more, no less. You can be quite sure that it compiles but you should check the CI build status. The CI also runs unit tests and experienced developers reviewed changes to the critical or important parts of the code base. ===== Guarantees ===== In addition to the Q0 guarantees: - Code certainly compiles on all [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 1 platforms]]. - Continuous and nightly (clean build) unit tests. - If the [[https://cdash.mitk.org/index.php?project=MITK | dashboard]] is not green on tier 1 for any reason, it will be promptly fixed. - Commits that touch core or other important parts of the source tree are reviewed by MITK developers. The review ensures that all guarantees are fulfilled and comprises an actual code review. The source scope is defined by: - {O1} - {O3} ===== Where ===== - //origin/develop// - release branches === Q2 - Beta level === For developers that are not depending on the UI/Qt parts of MITK, it is the save pick as green dashboard (unit tests) is guaranteed. All who want to use the Workbench or a like should be aware, that undetected errors in the UI might have slipped in as only fundamental smoke tests have been made and extensive UI checklist testing is *not* guaranteed at this level. So if you make UI developments, it is a good practice to first check the UI parts relevant for you, before starting your own developments. Otherwise it becomes hard for you to distinct, if problems that occur are introduced by your new changes or where already present at your starting commit. **Guarantees:** - All guarantees of Q1 - Commit are reflected in changelog. - Code compiles also on all [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 2 platforms]]. - Passed simple smoke tests for all [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 1 platforms]] - Installers are generated and install - Application starts and closes properly **Where:** origin/master === Q3 - Production level === Recommended for usage if you want the highest quality. e.g. for a production environment. But as a trade of, it does not provide the latest features, additions and improvements. **Guarantees: ** - All guarantees of Q2 - Passed checklist testing - Source scope: TBD - Documentation is up to date - Source scope: modules and plugins specified in here - https://phabricator.mitk.org/owners/package/1/ - https://phabricator.mitk.org/owners/package/3/ - All associated web resources are uptodate and official release installers are available on [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 1 platforms]] **Where:** commits in origin/master tagged as public releases

To ensure a good experience for developers or advanced users and to keep the work for the core team on a manageable scale, it is important to know what guarantees are given for different parts of the MITK Git repository. This allows... - developers to make a qualified decision if they want to play it safe, go bleeding edge (and we mean bleeding, so don’t cry if youso you may get cut ;) or something in between. - contributors (internal and external) whatto understand the definitions of done (DODs) are for contributions. The code guarantees are grouped into quality levels (Q0-Q3) which are used to easily reference/ and communicate quality promises and requirements in our release concept. ==Quality levels In the following we explain the different quality levels, their intended purpose and their given guarantees / quality measures. This helps developers and power users to pick the right starting point for their own builds or developments. Quality levels == Quality levels always have a repository scope. Meaning, that a branch/tag in the repository always has one specified quality level (e.g. origin/develop is Q1). The guarantees given in a quality level may only hold for a part of the source tree (e.g. in origin/develop the whole source tree compiles, but only a part of the source tree gets active code review).In the following we explain the different quality levels, That's why quality guarantees have a source scope;their intended purpose, if no source scope is specified,given guarantees and quality measures. one can assume a global scopeThis helps developers and power users to pick the right starting point for this guaranteeeir own builds or developments. ===Q0 - Work In Progress (WIP)Quality level Nearly no guarantees at all! This is ongoing work in progressels have a repository scope. You should *only* base your own work on or build this quality level if you really know what you are doing (eA branch/tag in the repository always has a certain quality level (e.g. you have talked to the branch owner and his given guarantees are sufficient,//origin/develop// is Q1). you are working on a closely related topic, etc.The guarantees given in a quality level may only hold for a part of the source tree (e.g. Developers are requested to ensure that all commits can bin //origin/develop// the whole source tree compileds, but even this is not an obligatory thing;only a part of the source tree gets active code reviews). not even for our tier 1 platforms. So,That's why quality guarantees have a source scope; be welcomed to the wild west and don’t say we haven’t warned you!if no source scope is specified, Yee Haw..the global scope is implied. **Guarantees:** - Branches are associated with a task, to follow the process and its history (even if the branch is merged and gone). Therefore all branch names obey the naming schema that encodes the task number: `T<tasknumber>-<human_readable_title>`=== Q0 - Work In progress (WIP) level === **Where:** feature/bugfix branches,Nearly no guarantees at all! This is ongoing work in progress. You should only build or base your own work on this quality level if you really know what you are doing (e.g. you have talked to the branch owner and his given guarantees are sufficient or you are working on a closely related topic). hotfix branchesDevelopers are requested to create compilable commits, support branchesbut even this is not obligatory. ===Q1 - CI level (aka Nightly level)So, be welcomed to the wild west and don’t say we haven’t warned you! Yee haw... ===== Guarantees ===== - Branches are always associated with a task, to follow the process and its history (even if the branch is merged and gone). Therefore, all branch names obey our naming convention that includes the corresponding task number. For details, see [[mitk/dev/git-branching]]. ===== Where ===== - feature and bugfix branches The compilable, CI monitored, bleeding edge; no more, no less. You can be sure that it compiles, that the CI checked the unit tests and that experienced developers reviewed changes to the critical or important parts of the code base. But that’s practically it.- hotfix branches - support branches **Guarantees:**=== Q1 - Continuous integration (CI) level === The certainly compilable, CI-monitored, bleeding edge; no more, no less. You can be quite sure that it compiles but you should check the CI build status. The CI also runs unit tests and experienced developers reviewed changes to the critical or important parts of the code base. ===== Guarantees ===== In addition to the Q0 guarantees: - Code certainly compiles on all [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 1 platforms]]. - All guarantees of Q0- Continuous and nightly (clean build) unit tests. - Code compiles on all- If the [[https://docscdash.mitk.org/nightly/SupportedPlatformsPage.html |index.php?project=MITK | dashboard]] is not green on tier 1 platforms]]for any reason, it will be promptly fixed. - Nightly unit tests. Green test state will be assured for all [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 1 platforms]]Commits that touch core or other important parts of the source tree are reviewed by MITK developers. If Dashboard is not green on tier 1 for any reason,The review ensures that all guarantees are fulfilled and comprises an actual code review. it will be promptly fixed.The source scope is defined by: - Comits are reviewed by MITK developer. The review ensures that all process guarantees (code compiles, unit tests…) are fulfilled and comprises a code review - Source scope: the source parts specified here - https://phabricator.mitk.org/owners/package/1/- {O1} - https://phabricator.mitk.org/owners/package/3/- {O3} **Where:** origin/develop, release branches===== Where ===== ===Q2 - Beta l- //origin/develop// - release branches === Q2 - Beta level === For developers that are not depending on the UI/Qt parts of MITK, it is the save pick as green dashboard (unit tests) is guaranteed. All who want to use the Workbench or a like should be aware, that undetected errors in the UI might have slipped in as only fundamental smoke tests have been made and extensive UI checklist testing is *not* guaranteed at this level. So if you make UI developments, it is a good practice to first check the UI parts relevant for you, before starting your own developments. Otherwise it becomes hard for you to distinct, if problems that occur are introduced by your new changes or where already present at your starting commit. **Guarantees:** - All guarantees of Q1 - Commit are reflected in changelog. - Code compiles also on all [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 2 platforms]]. - Passed simple smoke tests for all [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 1 platforms]] - Installers are generated and install - Application starts and closes properly **Where:** origin/master ====== Q3 - Production level === Recommended for usage if you want the highest quality. e.g. for a production environment. But as a trade of, it does not provide the latest features, additions and improvements. **Guarantees: ** - All guarantees of Q2 - Passed checklist testing - Source scope: TBD - Documentation is up to date - Source scope: modules and plugins specified in here - https://phabricator.mitk.org/owners/package/1/ - https://phabricator.mitk.org/owners/package/3/ - All associated web resources are uptodate and official release installers are available on [[https://docs.mitk.org/nightly/SupportedPlatformsPage.html | tier 1 platforms]] **Where:** commits in origin/master tagged as public releases