View source for Release branches/Pullup policy

{{policy}}
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 {{trunkref|doc/procedures.txt}} 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==

#The pullup implements or partially implements a release goal.
# 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==

#The pullup introduces new functionality that is not a release goal.
# The release engineer does not have sufficient confidence in the code quality of the change.
# 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 [[API]]s are.