Tuesday 14 May 2013

Re: Some status of ubuntu-touch stack into daily release and recent change

Le 14/05/2013 17:22, Iain Lane a écrit :
Hey Didier,    Thanks for the update, it's useful.    On Tue, May 14, 2013 at 04:22:31PM +0200, Didier Roche wrote:  
Hey guys,  […]  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).  
  I understand that things aren't releasing into saucy at the minute, but  into the "next" PPA instead. Is that right? Do you know when it might be  re-enabled and what the blockers are?

Some components like Qt 5.0.2 and other like libhybris and telepathy stack are not in saucy yet. I think the platform team and Ricardo has to update them soon (it's an action that was taken at previous vUDS).
We need to have the points I listed in my email fixed first, having at least one or two daily release where all tests passed, then, switching is just a parameter away.

I hope that we'll get that before end of month.
    
[…]  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.  
  Hmm, it was my understanding that we were going to do this (at least  where possible, in preference to individual commits) at the merge  proposal level instead — these usually have a commit message attached to  them and describe changes at a more coarse-grained level than the  individual commit in a manner which, to me at least, is more suitable  for the Debian changelog. I also then don't have to think about the fact  that every commit will end up in d/changelog.

That's why I'm speaking about commits to mainline, so yeah, only the commit that can be seen in bzr log (without any nesting commits) are now taken into account (I was taking care of deep commits before for getting the bug numbers). So we are aligned! Feel free to edit the wiki page if it's not clear enough :)
    Anyway I can totally understand that you probably don't want to revisit  all of this again, so let me end by saying that this is a big  improvement on what we had before and I think it'll make me a happier  reviewer and consumer. We can revisit the MP thing in time, if  necessary.    Cheers,