diff --git a/general/images/release.png b/general/images/release.png
index 0a99831173cdb215fea8f75680be66b3637823ef..5baf3c5d614ae3d7f0c9e7e3eb54eba17aa7288c 100644
Binary files a/general/images/release.png and b/general/images/release.png differ
diff --git a/general/publishing-packages.md b/general/publishing-packages.md
index 15f5075ad41eedb4ab8fc53ca27c5552f12124f9..915bdc2d71187f7a36c84ab9486b12ce476ddca7 100644
--- a/general/publishing-packages.md
+++ b/general/publishing-packages.md
@@ -29,25 +29,51 @@ Package build is divided roughly with following stages:
 * Package upload to public repositories (Manual)
 * Docker image build (Automatic)
 * Docker image release (Manual)
+* QA image and AWS AMI release (Manual)
 * Raspberry Pi package build (Automatic)
 * Raspberry Pi package release (Manual)
 
 ## Publishing packages
 
+Releasing packages to the public are handled using manual jobs in the pipeline.
+There are manual jobs for releasing the following
+1. Package for each supported OS (Raspberry Pi is a separate job)
+1. GitLab Docker image
+1. GitLab QA image
+1. AMI for AWS
+
+Note: In addition to the release jobs, the pipeline also contains an `upgrade`
+job that measures the time taken to upgrade from last minor version release to
+the current release.
+
+To make things easier for the release manager, two all-in-one trigger jobs are
+available that automates most of the above. They are
+1. `release:packages` - This job uses GitLab API to trigger all the individual
+   package release jobs automatically.
+1. `release:images` - This job uses GitLab API to trigger the release of GitLab
+   Docker image, GitLab QA image, and AWS AMI. It also triggers the upgrade time
+   measurement job.
+
 When the release is ready to be published to the public, release manager needs
-to start the manual job for:
+to follow these steps:
+
+1. Trigger the `release:packages` job. It uses GitLab API to detect all the
+   manual package release jobs associated with each OS and plays them. You can
+   confirm it worked as expected by checking the release pipeline - all
+   individual package release jobs would have been started automatically.
+1. Once all individual packages are released and available in the [package repository](https://packages.gitlab.com/gitlab/),
+   trigger the `release:images` job and make sure it triggers Docker, QA and AWS
+   jobs. Note: This should be done only after the packages are available in the
+   package repository. This is because some of these jobs pull the packages from
+   the repository for creating images.
+1. If Raspberry Pi package builds are over, trigger the Raspberry Pi release
+   job.
 
-* Package upload to public repositories
-* Docker image release
-* Raspberry Pi package release
+![Package build pipeline](images/release.png)
 
 *Note*: Raspberry Pi package builds can take a very long time to complete.
 The release can be completed without the finished Raspberry Pi package build.
-
-In order to push the package to public repositories, click on each manual job in
-the pipeline:
-
-![Package build pipeline](images/release.png)
+But do remember to release the Raspberry Pi package once the build is completed.
 
 ### FAQ
 
@@ -69,3 +95,9 @@ upload fails again, escalate to the Build team.
 
 In this case, retry the failed job. If the upload fails again, escalate to the
 Build team.
+
+#### What happens if the either of the all-in-one release jobs fail
+
+In this case, you can go ahead and manually trigger each of the individual
+package or image release jobs. The all-in-one release jobs basically does the
+same thing.