ubuntu-phone team mailing list archive

[Didier Roche <didrocks@xxxxxxxxxx>]

Hey guys,

Just wanted to share with you the current state of daily release for 
ubuntu-touch components and a recent improvement which will particularly 
please the release team.

1. Touch status

First, good news, there is progress! Most of you already saw some 
automated merging back I guess on a successful daily release run for 
your stack. We survived the hud transition and finishing up the 
autopilot 1.3 transition (which impacts both desktop version of our 
stack and touch ones).

You can see what successfully passed at least once at 
https://launchpad.net/~ubuntu-unity/+archive/next
You can see what's as been tested on 
https://launchpad.net/~ubuntu-unity/+archive/daily-build-next

So basically "daily-build-next" packages minus "next" packages is 
telling you what never passed the tests ;) (there is also some other 
bootstrap packages in daily-build-next like Qt, telepathy-*, libhybris 
that are there just so we can build the packages until they are into 
distro).

From what I know about, the last blocker is to have all autopilot tests 
passing:
- some apps have some tests failing
- the hud have some AP tests failing as well
- some components are getting retired early and being rewritten
- the recent Qt gave some troubles but it's getting fixed
- the sdk had some issues which are now fixed.

Once all that is settled down (what ?ukasz is working on the remaining 
issues right now with the different upstreams), we'll have daily release 
of all the components and be able to ensure that everything is delivered 
in a consistent way (and so only rely on the next ppa, on not on 
daily-build-next, which is the intermediate pre-validation one).


2. What is happening on your first daily release

As it took time to get everything under daily releasing, you maybe did 
some manual release meanwhile. Don't wonder if the first daily release 
will generate some debian/changelog duplication, this is only the first 
one (as the bootstrap commit isn't the exact one). Once you are seeing 
automated merge back of daily release, you shouldn't do anymore "manual 
release". The changelog is generated for you as explained in the next 
paragraph.


3. Consistency of changes

Remember that trunk is sacred, you shouldn't push anything to trunk that 
are going to break yourself, or even other components. If you are making 
breaking changes, ensure that all the consistent changes are pushing at 
the same time to trunk (before 00 UTC). Trunk should never regress (at 
least, on purpose ;)) is one of the most important condition of daily 
release.


4. Changes to how we generate debian/changelog.

After some discussion with the ubuntu release team and the touch team, 
we decided to finally list all the commits from the mainline branch 
automatically in debian/changelog instead of just listing bugs number 
and their titles linked to branches. This mainly comes from the raring 
release cycle feedback where we saw quite some empty changelog where no 
bugs were linked to any branch merged to mainline and nobody entered 
anything in debian/changelog.

A quick example I just run: http://paste.ubuntu.com/5664334/
You can see that:
- the version is automatically generated
- it collected all the commits and sorted it by person, nicely formatted 
into the changelog (with some parts removed).
- it appended the bug numbers if a bug number was provided in a commit 
message or linked to the merge proposal
- the infos put manually in debian/changelog were preserved
- commit from rev 108 doesn't have its commit message listed as it gave 
directly the info in the changelog.

Here are the rules explaining how this changelog is generated (and how 
to skip them):


     How do we populate the changelog

I'm sure you want the world to know what great modifications you have 
introduced. You will get this praise automatically, using the commit 
message you set on the mainline (either automatically merged or by a 
manual merge to trunk) attributed to you. Note that we expurge some of 
the "Fixes" and "Approved by" messages that were eventually 
automatically generated as well as reformatting the commit to just be a 
one liner cut every 80 characters. If a branch merged to mainline had 
more than one contributor, each ones will get the praise (and blame ;)) 
in the changelog.

If you have a bug linking to this change, we are collecting it as well. 
This happens if you link bugs to a merge proposal before it's approved 
(you link a branch to the bug report in launchpad), or use*bzr commit 
--fixes lp:XXXX*so that automatically links it for you when proposing 
the merge for reviewing, or put in a commit message something like*this 
fixes bug #...*.

Note that if you have directly edited debian/changelog in your merge 
proposal, this commit message will get ignored to avoid duplication (we 
consider you set all relevant infos there).

Also, if you are making a trivial change and don't want your typo fix to 
be listed, you can set "#nochangelog" into your commit message while 
merging to trunk and it will get ignored.


     I have a big change that needs to be mention explicitely in
     debian/changelog, and I don't think the commit message is
     meaningful enough

If you file manually the changelog message in debian/changelog, the 
daily release will keep your original message and ignore the commit 
message. Take care that it won't pick bugs linked to that merge as well.

You need then mention it manually in debian/changelog:*$ dch*

-> edit the change and save.

This is creating an UNRELEASED entry for you. Check that you don't have 
"raring" but UNRELEASED in the first line (make the change yourself 
before saving if it's not the case).

This means that you/do not/have to care about the version in the 
changelog, as long as you're creating a new entry when you need to. The 
daily release machinery will update the version to be correct when it 
makes the next release.


     I want one of my commit not being part of debian/changelog

If you are making a trivial change and don't want your typo fix to be 
listed, you can set "#nochangelog" into your commit message while 
merging to trunk and it will get ignored.


Those and more infos are available at 
https://wiki.ubuntu.com/DailyRelease/FAQ, do not forget to give it a 
look whenever you have a question on daily release.

As usual, I'm available on IRC (as didrocks) for any questions,
Hope you will like those changes,

Cheers,
Didier