NetBSD Release Engineering: Pull-up Requests

General Information

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. These requests are sent to us, the release engineering team, so that the changes to the release branch can be carefully monitored, and quality can be maintained.

Pull-up requests are sent to a branch-specific email address.

Policy issues or general questions for the Release Engineering team can go to .

Specific release issues/concerns should go to the appropriate list:

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 it 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 us. There's no point in making us figure all of that information from scratch, when you already know it and can easily pass it along to us.

Pull-up Preconditions

  • Pullups may not change the kernel ABI. In other words: everything that would cause a kernel version bump in -current can not be pulled up.
  • Pullups may not change interfaces in shared libraries. In other words: everything that would require a major version bump for the library in -current can not be pulled up.
  • A pullup may not cause other (binary) or pkgsrc incompatibilities. Binary packages build from the initial version of a branch need to work on all later versions.

Examples of things that are allowed:

  • Add a system call. This might sound strange at first, but we assume that the kernel is never older than libc.
  • Add a function to a shared library. The new function will not hurt any old binaries not using it.

Examples of things that are NOT allowed:

  • Change arguments of a system call. Neither adding, deleting, nor changing a type is allowed.
  • Delete a function from the kernel or a shared library.
  • Change arguments of a function exported from a shared library. Neither adding, deleting, nor changing a type is allowed.

Pull-up Requirements

  • Pull-up requests must always be sent by a developer who is responsible for checking 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 engineering team. It's not releng's responsibility to sanity check pull-up requests (though sometimes we will).
  • Pull-up requests to multiple release branches should be sent in separate email messages to the appropriate addresses.
  • Do not use resending (also known as bouncing) to submit a pull-up request. Either use forwarding or write a new e-mail.
  • Pull-up requests should contain accepted solutions to the problems that they address. That is, if a change was just made to the current NetBSD 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 in separate mail messages. That makes our bookkeeping job much easier.
  • cvs imports can not be pulled up by regular means. Either provide a patch, or request a sync-to-current.
  • When a pullup would get very hard or lengthy and its purpose is to bring a (set of) directory/ies up to date with -current, or a cvs import has happened, the request may instead include instructions to just sync some directory/ies with -current.
  • Pull-up requests must contain the following information:
    • A description of the problem fixed by the request (for the commit messages and, if a patch release is being generated, for the patch release's CHANGES file), including a list of any Problem Reports addressed by the request.
    • For each file to be patched, either;

      • A full copy of the email message containing the commit message that was sent to . Use the mail archives if you no longer have a copy of the mail. Do not quote or indent the message.

        If multiple revisions of a file are to be pulled up, please include a full copy of each of the emails sent to in chronological order. 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, in the latter example, 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 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, commit emails of those revisions should be included as in the previous case.)

        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 engineering team will do their best to be accommodating in accepting minor variations of the above. Do however note that the release engineering team 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.

Examples of Good Pull-up Requests

Here is an example of a good pull-up request:

From: Matthias Scheler <tron@NetBSD.org>
To: "NetBSD 1.6 Pullup Requests" <pullup-1-6@NetBSD.org>
Cc: Jun-ichiro itojun Hagino <itojun@NetBSD.org>
Subject: Urgent sendmail security fix

	Hello,

"sendmail" needs a security fix. Please pullup the following two
changes (more instructions below):

--------------------------------------------------------------------------

Module Name:	src
Committed By:	itojun
Date:		Wed Sep 17 14:16:23 UTC 2003

Modified Files:
	src/gnu/dist/sendmail/sendmail: parseaddr.c

Log Message:
fix prescan() bug (potentially remotely exploitable), CAN-2003-0694


To generate a diff of this commit:
cvs rdiff -r1.12 -r1.13 src/gnu/dist/sendmail/sendmail/parseaddr.c

--------------------------------------------------------------------------

Module Name:	src
Committed By:	tron
Date:		Wed Sep 17 20:23:02 UTC 2003

Modified Files:
	src/gnu/dist/sendmail/sendmail: version.c

Log Message:
Bump version number after parse8.359.2.8 patch has been applied.


To generate a diff of this commit:
cvs rdiff -r1.13 -r1.14 src/gnu/dist/sendmail/sendmail/version.c

--------------------------------------------------------------------------

The change to "version.c" will cause a conflict. I've therefore attached
a patch for this file.

	Thanks in advance

In detail:

  • The subject gives a short description of the purpose and the urgency.
  • It includes the commit message for both changes.
  • It contains a patch for the revision which cannot be applied directly.
  • The original committer received a copy of the pull-up request.

Pull-up Requests for security fixes

Pull-up requests for security fixes should have the keyword security in their subject line so that release engineering can easily recognize them. Depending on the urgency it might also be a good idea to try to contact one or more release engineers directly and point them to the ticket.

Special issues for pkgsrc releng

The usual pullup procedures are:

  • Only security fixes pulled up
  • Platform-specific fixes might be ok, but are clear second class citizens to the security fixes (i.e., security fixes should be pulled up with higher priority)
  • No one pulls up their own request
  • In case of doubt, ask

Back to  NetBSD Developer Documentation