canmove, Confirmed users
6,439
edits
ReleaseEngineering/Buildbot Best Practices: Difference between revisions
Jump to navigation
Jump to search
ReleaseEngineering/Buildbot Best Practices (view source)
Revision as of 15:32, 12 March 2009
, 12 March 2009→Check-in Policies
| Line 12: | Line 12: | ||
* Patches should not be checked in until you are ready to update the master with them. This helps to avoid situations where an urgent fix needs to go in, and a random unrelated patch ends up getting enabled at the same time. | * Patches should not be checked in until you are ready to update the master with them. This helps to avoid situations where an urgent fix needs to go in, and a random unrelated patch ends up getting enabled at the same time. | ||
* Production masters should never contain local changes. Even if you are just testing something you should check it in and pull it rather than making the change locally. Having temporary changes in the version control history is useful when debugging things later. | * Production masters should never contain local changes. Even if you are just testing something you should check it in and pull it rather than making the change locally. Having temporary changes in the version control history is useful when debugging things later. | ||
* If you have a patch that affects multiple masters you should update all of the masters when you land your patch. | |||
** This is less strict for staging masters. Eg, you shouldn't update a staging master if someone is currently using it. | |||
== How to land a patch == | == How to land a patch == | ||