wiki/info/landscape/development-environment.md
... ...
@@ -18,7 +18,7 @@ Everything else should follow the pattern
18 18
- when the workflow has finished, it triggers your Hudson job which collects the [build and test results](https://hudson.sapsailing.com/job/bug12345)
19 19
- be verbose and document your changes, progress, hold-ups and problems on your Bugzilla issue
20 20
- when build is "green," suggest your branch for review; so far we do this informally by assigning the Bugzilla issue to the reviewer and in a comment asking for review; in the future, we may want to use Github Pull Requests for this
21
-- after your branch has been merged into ``main``, disable your Hudson build job for your branch
21
+- after your branch has been merged into ``main``, disable your Hudson build job for your branch, comment about the merge in Bugzilla and resolve the Bugzilla item, usually as "FIXED".
22 22
- the ``main`` branch will then build a new release that you can roll out into the production landscape
23 23
- in case of changes to i18n-related message properties files, merge ``main`` into ``translation`` which triggers the translation process; the completed translations will arrive as pushes to the ``translations`` branch, triggering another ``release`` workflow, and---if successful---an automated merge into ``main`` with the corresponding build/release process happens, based on the [translation Hudson job](https://hudson.sapsailing.com/job/translation/configure)'s special logic
24 24
- a successful ``main`` build (still on Java 8) will lead to an automatic merge into one or more branches for newer Java releases (such as ``docker-24``) with the corresponding build/release process