Add directories and README files for staging changes.

While doing a release, problems were encountered running the
process-staging-changes script. These directories and the README.md
files were missing from the certified branches. Adding them in to be in
line with the other branches.

Also fixing the .gitreview file to point to the correct branch.

Change-Id: Ia9e2ecce31ef35838da5f3166aac321b577d16c2

diff --git a/.gitreview b/.gitreview
index c55b750fb091cd61476c16d646cb57748cccfdc2..4cd7762110d86cf7b0b9fa8dcee674a87f762198 100644 (file)
--- a/.gitreview
+++ b/.gitreview
@@ -1,5 +1,5 @@
 [gerrit]
-defaultbranch=certified/13
+defaultbranch=certified/13.21
 #
 # Intentional padding to ensure it is possible to point a commit
 # to an alternative gerrit server/repository without breaking

diff --git a/doc/CHANGES-staging/README.md b/doc/CHANGES-staging/README.md
new file mode 100644 (file)
index 0000000..8a2407f
--- /dev/null
+++ b/doc/CHANGES-staging/README.md
@@ -0,0 +1,37 @@
+## **DO NOT REMOVE THIS FILE!**
+
+The only files that should be added to this directory are ones that will be
+used by the release script to update the CHANGES file automatically. The only
+time that it is necessary to add something to the CHANGES-staging directory is
+if you are either adding a new feature to Asterisk or adding new functionality
+to an existing feature. The file does not need to have a meaningful name, but
+it probably should. If there are multiple items that need documenting, you can
+add multiple files, each with their own description. If the message is going to
+be the same for each subject, then you can add multiple subject headers to one
+file. The "Subject: xxx" line is case sensitive! For example, if you are making
+a change to PJSIP, then you might add the file "res_pjsip_my_cool_feature" to
+this directory, with a short description of what it does. If you are adding
+multiple entries, they should be done in the same commit to avoid merge
+conflicts. Here's an example:
+
+> Subject: res_pjsip
+> Subject: Core
+>
+> Here's a pretty good description of my new feature that explains exactly what
+> it does and how to use it.
+
+Here's a master-only example:
+
+> Subject: res_ari
+> Master-Only: True
+>
+> This change will only go into the master branch. The "Master-Only" header
+> will never be in a change not in master.
+
+Note that the second subject has another header: "Master-Only". Changes that go
+into the master branch and ONLY the master branch are the only ones that should
+have this header. Also, the value can only be "true" or "True". The
+"Master-Only" part of the header IS case-sensitive, however!
+
+For more information, check out the wiki page:
+https://wiki.asterisk.org/wiki/display/AST/CHANGES+and+UPGRADE.txt

diff --git a/doc/UPGRADE-staging/README.md b/doc/UPGRADE-staging/README.md
new file mode 100644 (file)
index 0000000..8147161
--- /dev/null
+++ b/doc/UPGRADE-staging/README.md
@@ -0,0 +1,36 @@
+## **DO NOT REMOVE THIS FILE!**
+
+The only files that should be added to this directory are ones that will be
+used by the release script to update the UPGRADE.txt file automatically. The
+only time that it is necessary to add something to the UPGRADE-staging directory
+is if you are making a breaking change to an existing feature in Asterisk. The
+file does not need to have a meaningful name, but it probably should. If there
+are multiple items that need documenting, you can add multiple files, each with
+their own description. If the message is going to be the same for each subject,
+then you can add multiple subject headers to one file. The "Subject: xxx" line
+is case sensitive! For example, if you are making a change to PJSIP, then you
+might add the file "res_pjsip_my_cool_feature" to this directory, with a short
+description of what it does. If you are adding multiple entries, they should be
+done in the same commit to avoid merge conflicts. Here's an example:
+
+> Subject: res_pjsip
+> Subject: Core
+>
+> Here's a pretty good description of my new feature that explains exactly what
+> it does and how to use it.
+
+Here's a master-only example:
+
+> Subject: res_ari
+> Master-Only: True
+>
+> This change will only go into the master branch. The "Master-Only" header
+> will never be in a change not in master.
+
+Note that the second subject has another header: "Master-Only". Changes that go
+into the master branch and ONLY the master branch are the only ones that should
+have this header. Also, the value can only be "true" or "True". The
+"Master-Only" part of the header IS case-sensitive, however!
+
+For more information, check out the wiki page:
+https://wiki.asterisk.org/wiki/display/AST/CHANGES+and+UPGRADE.txt