From 0e8a52a9f5027ae1019bb9477731e0ff889af23b Mon Sep 17 00:00:00 2001 From: Jehan Date: Mon, 12 Dec 2022 23:15:48 +0100 Subject: [PATCH] devel-docs: removing files and contents moved to developer.gimp.org. The milestone and libtool instructions were moved over, as well as "Maintainer" section text from the devel README. --- devel-docs/Makefile.am | 2 - devel-docs/README.md | 82 ----------------------------- devel-docs/gitlab-milestones.txt | 71 ------------------------- devel-docs/libtool-instructions.txt | 65 ----------------------- 4 files changed, 220 deletions(-) delete mode 100644 devel-docs/gitlab-milestones.txt delete mode 100644 devel-docs/libtool-instructions.txt diff --git a/devel-docs/Makefile.am b/devel-docs/Makefile.am index 618ccb8281..74a4a6c557 100644 --- a/devel-docs/Makefile.am +++ b/devel-docs/Makefile.am @@ -11,9 +11,7 @@ EXTRA_DIST = \ README.md \ contexts.txt \ debug-plug-ins.txt \ - gitlab-milestones.txt \ includes.txt \ - libtool-instructions.txt \ parasites.txt \ release-howto.txt \ tagging.txt \ diff --git a/devel-docs/README.md b/devel-docs/README.md index d229b6d2a1..142c7c949d 100644 --- a/devel-docs/README.md +++ b/devel-docs/README.md @@ -417,88 +417,6 @@ make you feel like developing on GIMP means developing for yourself. ### 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). -- Maintain [NEWS](/NEWS) file. Any developer is actually encouraged to - update it when they do noteworthy changes, but this is the - maintainers' role to do the finale checks and make sure we don't miss - anything. The purpose of this rule is to make it as easy as possible - to make a GIMP release as looking in this file to write release notes - is much easier than reviewing hundreds of commits. - -#### AppStream metadata - -One of the requirement of a good release is to have a proper `` -tag in the [AppStream metadata -file](desktop/org.gimp.GIMP.appdata.xml.in.in). This metadata is used by -various installers (e.g. GNOME Software, KDE Discover), software -websites (e.g. Flathub). Having good release info in particular will -help people know what happened on the last release, and also it will -have GIMP feature among the "recently updated" software list, when the -installer/website has such a section. - -Moreover we use this data within GIMP itself where we feature recent -changes in the Welcome dialog after an update. - -What you should take care of are the following points: - -* For the general rules on AppStream format, please refer to its - [specifications](https://www.freedesktop.org/software/appstream/docs/). -* Native language text are translated if a tag name starts with `_`. - Therefore do not use `

` but `<_p>` in the source. Same for `<_li>` - instead of `

  • `. These will be transformed by our build system. -* It also means you should push the `` text early to leave time - to translators. -* Since we use this data in GIMP itself, we stick to a specific - contents in a `` tag. In particular, all `` tags - must start with one or several `<_p>` paragraphs, followed by a `
      ` - list. -* Make sure the `date` and `version` attributes are appropriate. When - the release date is still unknown, setting "TODO" is a good practice - as our CI will `grep TODO` on even micro versions and fail on them. -* We have a custom feature in GIMP: adding `demo` attributes to `<_li>` - points of the release will generate a feature tour (basically blinking - several pieces of GIMP in order). - The format is as follows: - - demo steps are comma-separated; - - each step are in the form `dockable:widget=value`. You could write - only `dockable` (which would blink the dockable), or - `dockable:widget` (which would only blink the specific widget). - The full form would not only blink the widget but also change its - value (only boolean and integer types are supported for now). - - dockable names can be found in `app/dialogs/dialogs.c`. Since they - all start with `gimp-`, writing the suffix or not is equivalent. - - the widget IDs will default to the associated property. If the - widget is not a propwidget, or you wish to create a specific ID, - `gimp_widget_set_identifier()` must have been set explicitly to - this widget. - - as a special case, tool buttons (in `toolbox:` dockable) IDs are - the action names, so you can just search in `Edit > Keyboard - Shortcuts` menu. These are usually of the form `tools-*` so the - short form without `tools-` is also accepted. - - spaces in this `demo` attribute are ignored which allows to - pretty-write the demo rules for better reading. - ### 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 deleted file mode 100644 index a7bcf10d7c..0000000000 --- a/devel-docs/gitlab-milestones.txt +++ /dev/null @@ -1,71 +0,0 @@ -gitlab-milestones.txt ------------------------ - -This document describes how the GIMP project uses milestones in the -GNOME gitlab issue tracker found at: -https://gitlab.gnome.org/GNOME/gimp - - -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. - -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. - -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. - - -Next stable milestone ---------------------- - -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 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 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. diff --git a/devel-docs/libtool-instructions.txt b/devel-docs/libtool-instructions.txt deleted file mode 100644 index 1040a123ac..0000000000 --- a/devel-docs/libtool-instructions.txt +++ /dev/null @@ -1,65 +0,0 @@ -configure.ac libtool settings -============================= - -This is a brief description of how the various version variables at the -top of configure.ac are to be set, including gimp_interface_age and -gimp_binary_age. - -See the arithmetic under the "libtool versioning" comment heading in -configure.ac as a reference. - -See https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html -for definitions of libtool "current", "revision" and "age" numbers as -used below. - -When making a release ---------------------- - -(1) When making releases on the stable branch, set: - gimp_micro_version += 1; - gimp_interface_age += 1; - - If gimp_binary_age is defined as a constant, set gimp_binary_age += 1; - else if gimp_binary_age is defined as an m4_eval(), leave it as it is. - - The default gimp_binary_age m4_eval() expression auto-increments - itself. - -(2) NEVER increment gimp_interface_age and gimp_binary_age by more than -1 at any time for whatever reason, or you will have to wear a brown -paper bag on your head to hide your face for the rest of your life. If -you increment gimp_interface_age by more than 1, then the libtool -"current" number is decremented which could result in incompatible -library interface with existing bin programs. - -(3) If any functions have been added, set gimp_interface_age=0. This -will cause the "current" and "age" part of libtool version to bump -upwards, increasing the interface number the library implements while -keeping the minimum interface number supported the same as before -(i.e., backwards compatible ABI). - - Example: In GIMP 2.8.10, with gimp_minor_version=8, - gimp_micro_version=10 and gimp_interface_age=10 (incremented by 1 - for every micro release), current=800 and age=800, which means that - the libraries support interface numbers 0 through 800, and the - interface DID NOT change at all between GIMP 2.8.0 to GIMP 2.8.10. - - Example: In GIMP 2.8.12, with gimp_minor_version=8, - gimp_micro_version=12 and gimp_interface_age=0, current=812 and - age=812, which means that the libraries support interface numbers 0 - through 812, and the ABI interface DID change in backwards - compatible manner at the time gimp_interface_age was set to 0. - -(4) If backwards compatibility was broken, set gimp_binary_age=0 and -gimp_interface_age=0. This will cause "age" part of libtool version to -be 0, increasing the minimum interface supported to "current" part of -libtool version, and making ABI backwards incompatible (the linker -will not be able to use these libraries with programs compiled to work -against older libraries. - - Example: In GIMP 2.8.14, with gimp_minor_version=8, - gimp_micro_version=14, gimp_binary_age=0 and gimp_interface_age=0, - current=814 and age=0, which means that the libraries support - interface number 814 only, which tells libtool the ABI interface - changed in backwards incompatible manner at the time - gimp_binary_age was set to 0.