Merge window: Difference between revisions
No edit summary |
>Jmarshall No edit summary |
||
| Line 2: | Line 2: | ||
==Procedure== | ==Procedure== | ||
In order to minimise the periods where features are added to XBMC, and to encourage review of features prior to addition, the XBMC team operates a merge window policy. New features may only be merged from a pull request (PR) during the merge window. The rest of the time is left for bug fixing. | |||
If you have a simple bug fix, you can slot it straight into master whenever you like. If it is a non-trivial bugfix, then it's probably best to do a pull request, asking for the specific folk who should review prior to going in. | |||
If you have a new feature addition, then it needs to go through a pull request. Currently the merge windows are the 1st to the 10th of the month. Thus, if you have a new feature, you first do a pull request, and then solicit review. Assuming review brings up no issues, you can assign it to the merge window (using github issues) and pull it in during the 1st to the 10th of the month. If you miss the window, too bad - wait for the next month. | |||
If you do a pull request and get little feedback, then make sure you specifically request the feedback from those that are most appropriate to review. | |||
==See also== | ==See also== | ||
*[[XBMC development]] | *[[XBMC development]] | ||
Revision as of 06:13, 30 June 2012
This page describes the "merge window" procedure used by Team XBMC to merge pull requests into the master git branch.
Procedure
In order to minimise the periods where features are added to XBMC, and to encourage review of features prior to addition, the XBMC team operates a merge window policy. New features may only be merged from a pull request (PR) during the merge window. The rest of the time is left for bug fixing.
If you have a simple bug fix, you can slot it straight into master whenever you like. If it is a non-trivial bugfix, then it's probably best to do a pull request, asking for the specific folk who should review prior to going in.
If you have a new feature addition, then it needs to go through a pull request. Currently the merge windows are the 1st to the 10th of the month. Thus, if you have a new feature, you first do a pull request, and then solicit review. Assuming review brings up no issues, you can assign it to the merge window (using github issues) and pull it in during the 1st to the 10th of the month. If you miss the window, too bad - wait for the next month.
If you do a pull request and get little feedback, then make sure you specifically request the feedback from those that are most appropriate to review.