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
