From 15d3bca481f7128d768ca714f67b1c9f1f5e8866 Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Tue, 21 Sep 2021 09:36:57 +0300 Subject: docs: expand DONE.md to discuss merge policy Also be more verbose in general. Sponsored-by: author --- DONE.md | 40 +++++++++++++++++++++++++++++++++++----- 1 file 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. -- cgit v1.2.1