summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLars Wirzenius <liw@liw.fi>2021-09-21 09:36:57 +0300
committerLars Wirzenius <liw@liw.fi>2021-09-21 09:36:57 +0300
commit15d3bca481f7128d768ca714f67b1c9f1f5e8866 (patch)
tree4f77bd94bf1f011414486a3b949cd340f25edb35
parent7f3f30b0e4b7713d0a6106babf662127ac457210 (diff)
downloadobnam2-15d3bca481f7128d768ca714f67b1c9f1f5e8866.tar.gz
docs: expand DONE.md to discuss merge policy
Also be more verbose in general. Sponsored-by: author
-rw-r--r--DONE.md40
1 files changed, 35 insertions, 5 deletions
diff --git a/DONE.md b/DONE.md
index ab77fb8..aa6558c 100644
--- a/DONE.md
+++ b/DONE.md
@@ -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 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.