|Deletions are marked like this.||Additions are marked like this.|
|Line 2:||Line 2:|
== Overview ==
Below we outline two currently accepted ways of landing things to Ubuntu RTM. There is some flexibility in doing this, but one rule needs to be obeyed: any change that lands into 14.09 '''is required''' to land to the current development series (currently: vivid). Not obeying this rule will lead to confusion and chaos whenever the switch of focus happens. It might be indeed slower, but it will save everyone many problems in the future.
So remember: '''always''' land your changes to the current development series first!
Landing changes to Ubuntu RTM
Below we outline two currently accepted ways of landing things to Ubuntu RTM. There is some flexibility in doing this, but one rule needs to be obeyed: any change that lands into 14.09 is required to land to the current development series (currently: vivid). Not obeying this rule will lead to confusion and chaos whenever the switch of focus happens. It might be indeed slower, but it will save everyone many problems in the future.
So remember: always land your changes to the current development series first!
- Leave main bzr branch to target current development series (vivid)
- Create a separate branch for ubuntu-rtm
- First create a MP for the change for trunk (vivid)
- Land your change to Ubuntu through the normal landing process
- Cherry-pick the change to a branch targeting the ubuntu-rtm branch
- Submit a landing targeting ubuntu-rtm/14.09
- Land it separately
Source sync from vivid to 14.09
- Only one bzr branch for the project trunk
- Prepare a landing for vivid
- Release the silo for vivid
- Ask for a source sync silo from vivid to ubuntu-rtm
- Test and release the silo for ubuntu-rtm
This place tries to overview some of the possible methods of landing your Ubuntu changes to Ubuntu-RTM. As everyone knows, currently ubuntu-rtm is should be our main development focus - with a requirement that every change first lands in Ubuntu. This can be troublesome and we, the Landing Team, are trying to figure out possibilities of how to make this easier for everyone.
Separate branches, separate landings
Who is it for?
This approach is ideal for those projects that are not only focused on ubuntu-rtm or only some commits made to the development branch are safe enough for RTM.
A different bzr branch for ubuntu-rtm features. Common naming scheme: ubuntu -> lp:foo, ubuntu-rtm -> lp:foo/rtm-14.09
How to request such a landing?
Please mention explicitly in the landing that you do not want a source-copy ubuntu-rtm silo, and that you will fill in a separate landing with different MP for the ubuntu-rtm bits. 'Target distribution' field mentions if the landing is for ubuntu or ubuntu-rtm.
The first announced landing method. See https://lists.launchpad.net/ubuntu-phone/msg09565.html for more details.
Semi-automated dual landings using CI Train silo-synchronization
Who is it for?
This approach is perfect for those that want all of their changes in ubuntu-rtm. Perfect for projects that only want to have one branch (trunk) for both ubuntu and ubuntu-rtm.
Only one bzr development branch. Ubuntu and ubuntu-rtm in sync.
How to request such a landing?
This is the preferred and default way right now. Every ubuntu silo that is requested a landing will have an ubuntu-rtm sync silo assigned automatically by the Landing Team as well (if possible) - bound to the former. If you do not want this to happen, please let us know in the comments field.
The recently added sync possibility gives the lander an easier and more convenient way of building the ubuntu-rtm sources based on the ubuntu sources. So, if a lander has an ubuntu silo in which her/his MPs are built, the lander can now get the same sources present in the PPA rebuilt for ubuntu-rtm by simply pressing the build button on the ubuntu-rtm sync silo. A build on the ubuntu-rtm silo triggers a binary-copy from the bound ubuntu silo. The ubuntu-rtm packages are then instantly ready for testing without having to ask the Landing Team directly.
Please note that since these are direct binary copies from a different distribution, please test it with caution to make sure no build-dependencies are missing or invalid.
In cases where a binary copy is not the right way to go, you can simply press build with the REBUILD_SOURCES_FOR_SYNC flag set - this will fall back to the old 'rebuild sources' approach.