Landing changes through the CI Train

PLEASE NOTE: This document is still being worked on!

Landing your change to Ubuntu

This part might be well known to most landers that already performed landings through CI Train.

The train provides two possibilities - you can either land your changes into the archive through listing merge proposals that you want to release or by source packages directly. The first approach is recommended.

Whenever you want to request a release of your component to the archive:

• Open the CI Train spreadsheet https://wiki.ubuntu.com/citrain.

• On the main 'Pending' sheet add a new row to the list, filling out the required fields as they go.
  • Description of landing: write here an overview of what your landing is about - is it fixing bugs? Adding some features? Try being informative without being over-verbose.
  • Lander: your irc nick-name and/or of other people that will also drive the landing (space separated)
  • Comments: used for any additional comments and offline discussion with the Landing Team.

  • Test plans to run: each project handled by CI Train needs to have a test plan, best in form of a wiki page or other document, that overviews of how you, the lander, intend to test the given component. See #QA for more details.

  • Merge proposals to land: here you list all the links to the merge proposals you want to land in this landing. Please note we need a space separated list of MP links, not branch links. More on this later.

  • Additional source packages to land: here you list the 'additional' source packages that you would like to upload to the silo PPA besides what is already handled by MPs. Can be used for projects that Ubuntu is not upstream for or which have no bzr trunk.
  • Target distribution: select which distribution and series you want to land into.
  • QA sign off needed?:
  • Ready for a silo?: change this to 'Yes' once you think this landing is ready to get a silo assigned. Before this is done, the Landing Team will not allocate a silo.

QA Sign-off Needed

Under certain circumstances your landing may need to go through QA sign off. This is usually during situations when the quality level of the image has regressed severely or must be maintained at a high-level. Right now these are:

• During TRAINCON-0
• For all landings to the ubuntu-rtm branch

There is an exception to this rule if your landing contains an isolated bug fix. Right now there is not a strict definition of this term, but as guidance an isolated bug fix landing should contain:

• One, or only a couple of bug fixes
• The change should be small and not impacting a large number of sub-components of that package
• The package itself should not have a lot of reverse dependencies, since this makes it much harder to assess the impact of the landing.

If QA sign off is required then you will be expected to provide more detailed information about the testing you have done in the Test plans to run column of the landing spreadsheet so that QA have a good basis on which to build their additional testing. Here are some tips:

• Never just test that the bug(s) alone are fixed - remember the potential for regressions
• Look at what is actually landing and make sure testing is done for all the updated packages. For example if the primary intent of the silo is to fix music player controls, but the fix requires a media-hub update then you should probably run the whole media-hub test plan.

• Take into consideration the dependencies and reverse dependencies involved - ask yourself, who could I break? Ideally your packages test plan should have some guidance on this (for example see the Dependents/Clients section media-hub's test plan

• If you only provide a link to the test plan, then bear in mind that QA will assume you've run all the tests in that plan and they have passed. If tests then fail for a reason you haven't mentioned then it will cause confusion and delay the landing, so make sure to record all cases where you have not run a test or a test has failed (and why).

Lastly, if you don't use the citrain tool for installing the silo then you need to mention what steps you used to install the silo, since citrain is the assumed way.