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. NetBSD 6 pull-ups go to pullup-6 NetBSD 5 pull-ups go to pullup-5 NetBSD 4 pull-ups go to pullup-4 NetBSD pkgsrc pull-ups go to pullup-pkgsrc Policy issues or general questions for the Release Engineering team can go to releng . Specific release issues/concerns should go to the appropriate list: NetBSD 5 goes to releng-5 NetBSD 4 goes to releng-4 NetBSD pkgsrc goes to releng-pkgsrc 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 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 pullup 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. 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 source-changes . 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, include a full copy of each of the emails sent to source-changes . 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. 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 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. 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) Noone pulls up their own request In case of doubt, ask pkgsrc-pmc