ubuntu-phone team mailing list archive

[Łukasz 'sil2100' Zemczak <lukasz.zemczak@xxxxxxxxxxxxx>]

Hello everyone,

There has been a lot of announcements recently, phew. This one might
make life a little bit more convenient for both landers and LT members.
We have just added a new small functionality to the CI Train -
Synchronization Requests. Since we have 2 distinct distros right now and
the need for having the same landings on both appeared, such
functionality finally makes some sense.
This is the first step to the dual-target landing functionality we're
trying to enable as well. Read on for more information.

With the latest changes, any lander can request a silo that will attempt
to fetch source packages from the selected distro archive or PPA on
every silo build operation. Such silo configurations are called sync
requests.

 **
 * Requesting a sync from ubuntu to an ubuntu-rtm silo
 **

The new sync functionality adds a possibility to explicitly request a
sync from the ubuntu archive to ubuntu-rtm (others distros are also
possible). All that is needed to do is filling a landing request,
targeting it for ubuntu-rtm/14.09 and in the 'Additional sources to
land' you need to enter a special sync token followed by a
space-separated list of packages you want pulled in.

Example:
 sync:ubuntu,utopic unity8 qtmir unity-scope-scopes

The syntax for the sync token is, in overall:
 sync:archive,series packages_that_you_want_landed

Where archive can be either a distribution (like ubuntu or ubuntu-rtm)
or a PPA (like ppa:foo/ubuntu/bar).

Once such a landing gets a silo allocated, after executing the 'Build'
operation the silo will pull in the most recent packages from ubuntu and
build them for ubuntu-rtm.

 **
 * Requesting a sync from an ubuntu silo to an ubuntu-rtm silo
 **

This by default will be done automatically for you by the Landing Team
members whenever an ubuntu landing will be filled in.

Everyone can manually request a silo that will basically take packages
from an ubuntu silo, retarget those, modify the version and push to the
ubuntu-rtm silo. This way a lander can have one ubuntu silo where he
develops the ubuntu parts and another ubuntu-rtm silo that will fetch
packages from the former whenever requested and rebuild those for
ubuntu-rtm. Whenever the lander thinks the packages in the ubuntu PPA
are ready for building/testing in ubuntu-rtm - all he needs to do is
press 'Build' on the ubuntu-rtm silo. The silo will then sync the
packages and build them for RTM.

In this case all is the same as before, with the change that it can now
be the lander that decides when he wants to have ubuntu-rtm packages
built in his PPA. This can help testing when one wants to make sure that
the feature works on both channels the same way.

In case someone wants to fill in such a landing himself, the token
syntax is as follows:
 sync:ppa:silo_ppa,series packages_that_you_want_landed

Example:
 sync:ppa:~ci-train-ppa-service/ubuntu/landing-008,utopic appmenu-qt5

 **
 * Small note about building sync silos
 **

Please remember that the same rules apply to sync silos as with normal
silos with MPs. So, the first build builds 'all packages' that are
listed in the silo. Any other builds (at least for now) require listing
which exact packages you want rebuilt.

 **
 * A quick word about the ubuntu-rtm versioning scheme
 **

The standard way we are versioning things in CI Train whenever a
ubuntu-rtm targeted landing is considered is the following:

<source_version>+14.10.<date>~rtm-0ubuntu1

Example: 0.3+14.10.20140828.2~rtm-0ubuntu1

It's the same way as in case of normal ubuntu CI Train uploads just with
an additional ~rtm suffix appended to the upstream version part.
Generally every time a sync landing to ubuntu-rtm happens the suffix is
added to the version number before upload. This is to ensure that we
won't have two binary packages with the same version number from
different distributions with different contents.


I hope this will make the RTM landing trip a bit more pleasant now for
everyone, at least until the dual-landing code is well tested.

Remember that there might be some issues here and there - we apologize
for any inconveniences.


Best regards,

-- 
Łukasz 'sil2100' Zemczak
 lukasz.zemczak@xxxxxxxxxxxxx
 www.canonical.com