Release branches/Pullup policy

This page represents an official policy of the MIT Kerberos project. Edit this page only in accordance with changes agreed by the community; other changes will be reverted. The pullup policy describes the policy that Release Engineers follow when making a decision about whether a change should be pulled up to a release branch. See doc/procedures.txt (raw | annotated | history) for the mechanics of how a ticket is marked for pullup and how state is managed for tickets when the release engineer does the pullup.

Managing targets

The easiest way to avoid getting in a rush about whether a particular pullup request should be accepted is to mark the target_version of the ticket as soon as the developer believes that this change should block a given release. This may be before a specific fix is available. This gives the release engineer an opportunity to evaluate whether they would consider any fix to the given issue. If they believe that the issue is not serious enough to risk a fix at the current stage in the release process, they can push back. If they believe that the fix should be considered if it arrives by a given time then they can make this response. The developer then has an opportunity to disagree.

Developers should include justification in the ticket when they set the target_version explaining why this ticket should block the release. If the developer believes a ticket needs to be included by a specific alpha or beta they should note this in the text of the ticket.

Responding to Pullup requests

All pullup requests should be responded to prior to the next testing release or final release. It is particularly important to decide whether a pullup introducing new functionality is introduced prior to the final alpha release and a pullup introducing other changes prior to the final beta. Accepting pullups in these categories later would require additional testing releases or a variance from standard practice. However even if a given pullup could wait until another scheduled testing release it should be responded to before the current release.

The developer submitting the pullup request should be given an opportunity to disagree with a decision by the release engineer not to pull up a given change. If there is a disagreement see dispute resolution. Developers are expected to be able to raise concerns regarding a pullup request within two days via email. Release engineers may often need to accelerate this process by making a phone call.

Silence is consent

handling of pullup requests is one of the few areas where for efficiency reasons silence is consent. Developers need to make any objections to release engineer decisions in a timely manner. If objections are not made in a timely manner, the decision stands. Release engineers need to give developers and opportunity to make these decisions. If they can wait two days, email may be appropriate. Otherwise, phone or in-person communications are required.

Reasons to accept a pullup

1. The pullup implements or partially implements a release goal.
2. The pullup fixes a bug.

Note that release goals are periodically reviewed during the release process and that release goals that have not made sufficient progress are often dropped from the release. However while a release goal remains, the community believes that finding a sufficiently low-risk way to meet that goal in the release time line is possible. If the release engineers realizes they question this assumption while evaluating a specific pullup they may propose dropping a release goal.

Reasons for rejecting a pullup

1. The pullup introduces new functionality that is not a release goal.
2. The release engineer does not have sufficient confidence in the code quality of the change.
3. The pullup introduces new user-visible functionality into a beta release. This needs to happen during the alpha cycle.

Note that for KFM and KFW new APIs are often not considered user-visible functionality. However for the core Kerberos release public APIs are.