[gimp] devel-docs: update further the devel docs.

[Jehan <jehanp src gnome org>]

commit 67a1d9f4d06a5419b16e91747bc3f302536f5aec
Author: Jehan <jehan girinstud io>
Date:   Sat Jan 22 23:00:50 2022 +0100

    devel-docs: update further the devel docs.
    
    Add more links to other files after I reviewed they were still relevant.
    
    The `gitlab-milestones.txt` in particular had to be updated because the
    contents was outdated (though we still need to manage milestones, simply
    now we are a bit more fine-grained).

 devel-docs/README.md             | 30 ++++++++++++++++++
 devel-docs/gitlab-milestones.txt | 66 +++++++++++++++++++++++++++++-----------
 2 files changed, 78 insertions(+), 18 deletions(-)
---
diff --git a/devel-docs/README.md b/devel-docs/README.md
index b6a5b16e3c..572ae95c72 100644
--- a/devel-docs/README.md
+++ b/devel-docs/README.md
@@ -221,10 +221,40 @@ repository.
 Eventually we want to move this pipeline to Gitlab as well.
 
 ## Core development
+
+When writing code, any core developer is expected to follow:
+
+- GIMP's [coding style](/CODING_STYLE.md);
+- the [directory structure](#directory-structure-of-gimp-source-tree)
+- our [include rules](includes.txt)
+
 ### Newcomers
 
 ### Core Contributors
 
+### Maintainers
+
+GIMP maintainers have a few more responsibilities, in particular
+regarding releases and coordination.
+
+Some of these duties include:
+
+- setting the version of GIMP as well as the API version. This is
+  explained in [libtool-instructions.txt](libtool-instructions.txt).
+- Making a release by followng accurately the process described in
+  [release-howto.txt](release-howto.txt).
+- Managing dependencies: except for core projects (such as `babl` and
+  `GEGL`), we should stay as conservative as possible for the stable
+  branch (otherwise distributions might end up getting stuck providing
+  very old GIMP versions). On development builds, we should verify any
+  mandatory dependency is at the very least available in Debian testing
+  and MSYS2; we may be a bit more adventurous for optional dependencies
+  yet stay reasonable (a feature is not so useful if nobody can build
+  it). In any case, any dependency bump must be carefully weighed within
+  reason, especially when getting close to make the development branch
+  into the new stable branch. See also [os-support.txt](os-support.txt).
+- Maintain [milestones](gitlab-milestones.txt).
+
 ### Directory structure of GIMP source tree
 
 GIMP source tree can be divided into the main application, libraries, plug-ins,
diff --git a/devel-docs/gitlab-milestones.txt b/devel-docs/gitlab-milestones.txt
index 6ea285a08d..a7bcf10d7c 100644
--- a/devel-docs/gitlab-milestones.txt
+++ b/devel-docs/gitlab-milestones.txt
@@ -6,14 +6,32 @@ GNOME gitlab issue tracker found at:
 https://gitlab.gnome.org/GNOME/gimp
 
 
-Stable milestone
-----------------
+Stable milestones
+-----------------
+
+We will create one milestone per micro-point release, as well as one per
+minor-point release. For instance, if GIMP 2.10 is the stable release
+branch, we will have a `2.10.32` milestone as well as a `2.10`
+milestone.
+
+Add reports to the next micro-point milestone when you expect to
+fix/implement the bug or feature in this time frame; add it to the
+minor-point milestone if you expect (or hope) to fix/implement in one of
+the stable release yet doubt if will happen in the next release.
 
-The bugs on a stable milestone, e.g. on the 2.8 milestone if GIMP
-2.8 is the stable release, are bugs for which fixes will be accepted
-onto the stable branch.
+When planifying a new release, a maintainer must create the next
+micro-point milestone shortly before releasing and start moving any
+still opened report which could not be solved to this new milestone. For
+instance before releasing 2.10.32, create the milestone `2.10.34`, then
+go through all opened reports in `2.10.32` and move them to `2.10.34`
+(unless someone expects to fix some at the last minute). When closing a
+milestone, it must not contain any opened report.
 
-Reports for bugs that are fixed in the stable branch should have the
+The `2.10.32` milestone will be closed when GIMP 2.10.32 was released.
+The `2.10` milestone will be closed only when no point releases are
+expected in the 2.10 branch anymore.
+
+Reports that are fixed in the stable branch should have the relevant
 stable milestone set. Usually such a fix is done in the development
 branch and then cherry-picked to the stable branch.
 
@@ -21,21 +39,33 @@ branch and then cherry-picked to the stable branch.
 Next stable milestone
 ---------------------
 
-The bugs/enhancement requests on the next stable milestone, e.g. on
-the 2.10 milestone if GIMP 2.8 is the stable release, are bugs or
-enhancement requests scheduled and planned for inclusion in the next
-stable version. This list is rather dynamic and will be altered during
-the execution of a development cycle.
+Similar rules apply to the next stable branch, for instance `3.0`
+minor-point milestone and individual `2.99.10` micro-point milestones.
+
+Note that any new feature must always be implemented in the next
+stable milestones first. Indeed we don't want regressions (new features
+popping in a 2.10 version then disappearing in 3.0). Yet they may be
+backported later if some developers are willing to work on it. When this
+happen, the report's milestone may be updated to the first version which
+gets the feature.
 
-If you fix a bug or implement a feature request for the next release,
-then please make sure that the milestone is set accordingly. This
-allows us to make a list of changes by looking at the resolved bugs on
-the milestone.
+If you fix a bug or implement a feature request for a release, then
+please make sure that the milestone is set accordingly. This allows us
+to make a list of changes by looking at the resolved bugs on the
+milestone.
 
 
 Future milestone
 ----------------
 
-The bugs/enhancement requests on the Future milestone are things that
-the GIMP project eventually want to include in a future version, but
-in what version is not yet decided.
+The bugs/enhancement requests on the `Future` milestone are things that
+the GIMP project eventually wants to include in a future version, but in
+what version is not yet decided.
+
+Note that "decision" is a fluid notion. Indeed it mostly means that
+someone cared enough for it to implement it properly. Therefore all it
+takes is one of the developers making a point to work on a feature in a
+given time frame.
+Within such logic, the `Future` milestone is really more of a way to
+tell that an improvement is a good idea, hence we'd be happy to have it,
+yet nobody took on the task.