diff options
author | Alexander Batischev <eual.jp@gmail.com> | 2021-09-21 11:37:34 +0000 |
---|---|---|
committer | Alexander Batischev <eual.jp@gmail.com> | 2021-09-21 11:37:34 +0000 |
commit | 7d037bdf8231f14c668cc36789ca2873ccaf3b45 (patch) | |
tree | b971d8772de19c8b2b86bafe54ac8d2c7c32eda2 | |
parent | 7f3f30b0e4b7713d0a6106babf662127ac457210 (diff) | |
parent | e332fa15343b523fcd2452d3efd51d72e6e88509 (diff) | |
download | obnam2-7d037bdf8231f14c668cc36789ca2873ccaf3b45.tar.gz |
Merge branch 'merge-policy' into 'main'
docs: expand DONE.md to discuss merge policy
Closes #127
See merge request obnam/obnam!183
-rw-r--r-- | DONE.md | 40 |
1 files changed, 35 insertions, 5 deletions
@@ -4,10 +4,40 @@ title: Definition of done # Definition of done +This definition is not meant to be petty bureaucracy. It's meant to be +the grease that allows the gears of project to turn smoothly with +minimal friction. The goal here is to enable smooth, speedy +improvement without having to frequently go back to fix things. + +When the software, automated tests, documentation, or web site +produced by the project are changed, the change overall should make +things better in some way: a bug is fixed, a feature is added, the +software becomes nicer to use, the documentation more effectively +communicates how to use the software, the tests cover more of the +functionality, the code is nicer to maintain, or something like that. + +At the same time, the change shouldn't make things significantly worse +in any way. A change that, say, makes the software ten times as fast, +but adds a ten percent chance of deleting the user's data would not be +acceptable. + For changes to this project to be considered done, the following must -be true: +all be true: + +1. New functionality and bug fixes are verified by automated tests + run by the `./check` script. + - if this is not feasible for some reason, that reason is + documented in commit messages, and an issue is opened so that the + tests can be added later +2. The build and tests run by GitLab CI finish successfully. +3. There has been sufficient time to review the change and for + interested parties to have tried it out. + - the time needed depends on the scope and complexity of the change + - a quick, easy change can be merged at once + - a complex change should be open for review and testing for a few + days -* any changes for new functionality add tests for the functionality -* changes are merged to the main branch -* the automated tests, as invoked by ./check, pass successfully -* CI successfully builds a new .deb package +If all of the above conditions are met, the change can be merged into +the main line of development by any person authorized to merge on +GitLab. The merge will eventually, automatically trigger a build of +Debian packages by Lars's personal CI. |