Release Engineering Team Change Request Requirements

If something is not clear...

If you are not sure about something during the code freeze, please ask. This Committers Guide entry outlines the typical order in which you should try to find the answer to your question.

If you are still unable to find an answer, please ask. re@ would prefer to receive "one more email" if it would clear up any confusion. Otherwise, we have no way to know that something is not clear.

If a question is asked enough times, we will document it.

Before reading further...

Do not use Subversion 1.6.x, as it can incorrectly record merge history.

Introduction

In order to submit a patch to the Release Engineering Team for a branch during Code Freeze you must be a FreeBSD Developer with proper commit privileges to commit the patch. If you are not a committer you need to contact a committer and have them submit the request. You only need to send a request when committing to a branch that is in code freeze. For most releases it will be a stable branch that gets frozen first (for example stable/8). But as the release process progresses the release branch (for example releng/8.2) will be created. After the release branch is created it will be frozen and the Release Engineering Team will release the code freeze on the stable branch. So for most cases you will need to submit requests for you will be requesting a merge, not a direct commit and that is what is described in the first section below. Only during the first part of the release process for a brand new stable branch (an X.0 release) would head be frozen. That situation is described in the second section below.

Note to committers that normally require approval for commits:

Before sending the approval request to re@, the commit should already have the approval that would normally be required. This means that before sending the change to re@, approval must have already been granted by mentor(s)/maintainer(s)/etc. When re@ receives the approval request, the change should be ready to commit immediately upon receiving re@ approval. Please indicate in your request for commit approval that the change has been approved by the mentor(s)/maintainer(s)/etc.

It is also recommended to CC the approver(s) of the change when sending the request for approval to re@.

Also please be sure to include the proposed commit message with the change request.

Change Request Requirements

IMPORTANT: Code reviews marked as 'Accepted' in Phabricator, regardless of if the reviewer of the change is a member of re@, are not implicit approval for the change to be committed to the tree. The guidelines outlined here must be adhered to, and any commit violating this policy will be reverted without further question.

Please follow these requirements when submitting patches for anything other than head. All submissions must:

  1. Include complete patches inline or attached to the e-mail generated as described below. Just forwarding the MFC reminder email message or sending a URL to the changeset description of the original commit on http://svn.freebsd.org/ is not sufficient.

  2. The diff should be generated from a tree that has been fully prepared for the commit. Use "svn diff -x -up" in that tree relative to src/ (from the top level of the branch). Use "svn diff -x -up --show-copies-as-adds" when merging from head so that newly-added files to that stable/X branch are included in the diff.

  3. See Subversion Primer for information about where in the tree merges should be done for non-kernel code. If done properly the output of "svn diff -x -up" should include the mergeinfo.

  4. The change should be fully build- and run-time tested.
  5. If the change is something that would normally, by standard FreeBSD Project practice, require review mention the information about who has reviewed the change.
  6. Include a 2-7 word summary, and a full proposed commit message.

  7. If not sending the request from your FreeBSD email address, mention your login in the email.
  8. Include the head revision number that will be merged and the branch(es) you intend to merge to, or indicate if it is a direct commit and why.
  9. Unless exceptional circumstances apply, the change should have been in head for at least three days before a merge is requested (which is standard FreeBSD Project policy). If a MFC timeout had been specified in the original commit you should wait for that time to expire before sending in the commit request. Please do not send in the commit request before the MFC time expires. The entire point of the MFC timeout period is to give some time for other developers to comment on the change and/or have it get a little testing. So until the MFC time expires you are not actually sure you should do the MFC. The only time you should send in the request early is if, prompted by mail from the RE Team saying that a "release event" is coming up (for example a BETA or RC build), you want to make sure your change is included in that "event". Sometimes it's better to MFC something a little early so it is included in a BETA or RC build.

As mentioned in the Introduction, during the late stages of the release process the Release Engineering Team creates the releng branch (for example releng/8.2) and unfreezes the corresponding stable branch (for example stable/8). When the release process is at that stage you can do the merge to the stable branch without requesting approval first, and at that point prepare a request to merge the change from the stable branch to the releng branch (for example the request should be an svn merge from stable/8 to releng/8.2).

Please follow these requirements when it is head that is in code freeze (the start of a X.0 release):

  1. Include complete patches inline or attached to the e-mail generated as described below.
  2. The diff should be generated from a tree that has been fully prepared for the commit. Use "svn diff -x -up" in that tree relative to src/ (from the top level of the head branch). If merging from a vendor/ or projects/ branch, use "svn diff -x -up --show-copies-as-adds"

  3. The change should be fully build- and run-time tested.
  4. If the change is something that would normally, by standard FreeBSD Project practice, require review mention the information about who has reviewed the change. The Release Engineering Team will be deciding if your request is "too risky" to be part of the release given the current state of the release process. We are NOT a substitute for normal FreeBSD Project maintainer, peer, or community review practices.
  5. Include a 2-7 word summary and a full proposed commit message.

  6. If not sending the request from your FreeBSD email address, mention your login in the email.

Requests that do not follow these requirements may be rejected without further consideration.

Contact the release engineering team if you require assistance with the use of svn merge.

Releng/ChangeRequestGuidelines (last edited 2015-07-03 02:11:32 by GlenBarber)