GGI Developer Documentation

Release Engineering: Pullup Requests

Release branch pull-up requests are the mechanism by which developers request changes to be pulled up to a release branch after the source tree has been branched for release, and by which they request that changes be pulled up for subsequent patch releases.

Pullup requests are submitted to the SF 'pullup requests' tracker (Hint: This tracker is visible for logged in developers only)

This page gives guidelines for pull-up requests.

Explained this way, it probably seems like pull-up requests are a lot of work. In a sense, they are. Before you submit a pull-up request, you should have verified and tested it, and you should have a good understanding of what is changing. However, that's work you've already done before you should even think about submitting the request. The only additional work is documenting that information for the release maintainer(s). There's no point in making them figure all of that information from scratch, when you already know it and can easily pass it along to the release maintainer(s).

Pullup-Requirements

  • Pull-up requests must always be sent by a developer if the change is eligible for an update release.
  • Pull-up requests should be tested in the release branch before being submitted to the release maintainer(s).
  • Pull-up requests to multiple release branches or libs should be made separately.
  • Pull-up requests should contain accepted solutions to the problems that they address. That is, if a change was just made to the -current sources, and is being debated, don't submit a pull-up request until resolution has been reached.
  • Multiple files can be modified by a single request, but each request should address a single problem. Independent requests should be submitted separately. That makes the bookkeeping job much easier.
  • Pull-up requests must contain the following information:

    • A description of the problem fixed by the request (for the commit messages and), including a list of any Problem Reports addressed by the request.
    • For each file to be patched, either;

      • A full copy of all email messages containing the commit message, the files and the path to it and the revision numbers that was sent to one of our cvs ML's. Use the mail archives if you no longer have a copy of the mail. URLs to the CVS mails in the archive are fully sufficient. Alternatively, just mention the commit messages, the files (including their paths) and the revision numbers.
      • If multiple revisions of a file are to be pulled up, include a full copy of each of the emails sent to a CVS ML. The changes in the specified revisions will be pulled up to the release branch.

        Please do not submit requests like "everything up to revision N," or "make it match -current." Requests like this are more difficult because releng needs to figure out the starting revision for the pull-up (for the commit message). That can be complicated by other revisions having been pulled up, for instance. It's better to have the person requesting the pull-up do that, because they already know what they want pulled up. Also there's the possibility that someone will commit something to the file between the time that the request is made and the time that it is processed, which may lead to insufficiently-tested changes being pulled up.

        If there are conflicts involving anything other than RCS IDs (the first line) the pull-up request will be rejected and you will be asked to resubmit it.

      • A patch file to be applied to the source tree. (If the patch just implements pull-ups of revisions that were otherwise prevented by conflicts, those revisions should be noted.)

        The patch file will be applied with patch. If any special instructions are necessary to apply the patch, they should be included in the pull-up request.

        If there are any conflicts at all, the pull-up request will be rejected and you will be asked to resubmit it.

    In general, it's best if all of the file and revision information is placed together, near the beginning of the pull-up request. It shouldn't be necessary to dig through a huge patch to figure out what steps to take. Additionally, if a patch really is just the difference between two revisions and applies cleanly, that should be noted (and a patch to do the same thing should be omitted).

With that said, it is also true that the release maintainer will do the best to be accommodating in accepting minor variations of the above. Do however note that the release maintainer will typically have their hands more than full enough during the release cycle, so please do not deviate too far afield from the requirements set forth above.