• PushingToReleaseBranch

Pushing Patches to a Release Branch

Each GDB release branch goes through two stages:

• Stage 1: Before the first release on that branch.

• Stage 2: After the first release on that branch.

Requirements during Stage 1

The only requirement for pushing a commit to a release branch during stage 1 is the following:

• A Global Maintainer must approve the commit for that branch.

Requirements during Stage 2

The requirements for pushing a commit to a release branch once in stage 2 are:

• All requirements from Stage 1 (see above);

• The commit must have an associated PR number in the GDB bugs database.

• The PR's Target Milestone field must be set to that branch's next release.

This is to create easily trackable documentation of the list of changes made by each corrective release we publish.

Frequently Asked Questions

I don't have a PR number, how do I create one after the fact?

Here is how:

• Log on to the GDB bugs database.

  • (if you do not have an account yet, click on the New Account link to create one first)

• Click on "File a Bug", then select "gdb";
• Provide as much information as you can.
  • Subject: Something descriptive; Tip: Could it be the subject of the commit you want to push?
  • Body: A description of the issue you are trying to solve; Tip: Could it be part of your commit's revision log? Or could it be copy/pasted from discussion that occurred on the gdb-patches mailing list?
  • Any other information that you would deem useful
• Submit the request to bugzilla, which will then return a PR number.

You can then use that PR number and update your commit to include that PR number in the ChangeLog as described in our Contribution Checklist.

How do I mark a PR as fixed in a given release?

• Log on to the GDB bugs database;

• Type your PR number in the search field;

• Once bugzilla displays the record for your PR, change the Target Milestone field to the correct release version, and click on Save Changes.

I forgot to add a PR number before I pushed to the branch during Stage 2

It is very easy to forget to add a PR number, but it is also very easy to adjust after the fact:

• Create a PR (see this procedure);

• Push a commit on the branch that adds the PR number to your ChangeLog entries

  • (the format is described in our Contribution Checklist)

• Open your new PR in bugzilla;

• Change the Target Milestone field to the correct release version;

• Add a URL to the gdb-patches discussion where the patch was discussed and approved for the branch, so as to record how the patch was fixed;
• Change the status to fixed
• Save your changes.