Difference between revisions of "Revert Policy"

From Openembedded.org
Jump to: navigation, search
 
(3 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Reverting someone elses work is by far the greatest source of friction
+
Reverting someone elses work can be a great source of friction in OE. As such, these need to be handled carefully, preferable on technical grounds rather than personal ones. Some cases are clear, e.g. if the orignal patch author requests a revert then this should generally be accepted.
in OE. As such, these need to be handled carefully, preferable on
+
technical grounds rather than personal ones.
+
  
Reverts may only be carried out with either
+
Now that OE uses layers, the situation is relatively clear since each layer has clear and documented maintainership and it is up to the layer maintainership to make decisions on whether code should be reverted.  
# Acks from two TSC members not associated with original change.
+
# An Ack from the original patch author.
+
  
This means you may revert your own mistakes.
+
In cases where there is any doubt, the OE TSC has final decision and authority.
  
 
[[Category:Policy]]
 
[[Category:Policy]]
 +
[[Category:Quality Assurance]]

Latest revision as of 10:13, 7 November 2012

Reverting someone elses work can be a great source of friction in OE. As such, these need to be handled carefully, preferable on technical grounds rather than personal ones. Some cases are clear, e.g. if the orignal patch author requests a revert then this should generally be accepted.

Now that OE uses layers, the situation is relatively clear since each layer has clear and documented maintainership and it is up to the layer maintainership to make decisions on whether code should be reverted.

In cases where there is any doubt, the OE TSC has final decision and authority.

Personal tools
Namespaces

Variants
Actions
Navigation
Categories
OE services
Toolbox