ubuntu-phone team mailing list archive

[Nicholas Skaggs <nicholas.skaggs@xxxxxxxxxxxxx>]

On 03/20/2014 03:01 PM, Sergio Schvezov wrote:
> On Thu, Mar 20, 2014 at 3:49 PM, Nicholas Skaggs
> <nicholas.skaggs@xxxxxxxxxxxxx> wrote:
> > On 03/20/2014 01:43 PM, Sergio Schvezov wrote:
> > > I have no issue with sharing but traceability is really lost if it's
> > > too many people with the same account.
> > The issue here isn't people to upload things, it's people to debug issues,
> > fix them and test them. Uploads happen as soon as fixes are landed, and in
> > general we've not had any delays if the fix is really ready and passes store
> > review. That said, we need someone who can be a counterpart in US TZ's to do
> > the store review for when we have a late upload, so we don't have to depend
> > on popey or waiting for Europe to awake again.
> hmm, AFAIK jdstrand and beuno can review as can myself
Good to know, ty.
> > On the debug/fix side, we've been uncovering low levels issues in our stack
> > with these AP test failures. It's indicative of gaps in our testing. For the
> > system apps, trunk = image, but for the community core apps this is not the
> > case. For community core apps, the store = image. I know this has caused
> > both confusion and frustration as well as hidden regressions in the past.
> > For example, both calendar and file manager are currently experiencing
> > regressions in trunk caused by underlying things changing. Clock just had
> > it's share of 2 of these regressions as well last week.
> >
> > https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1295242
> > https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1294181
> >
> > This causes the fun situation where the image is broken and trunk is broken.
> > You can't release trunk without fixing the regression. And you can't fix the
> > image without releasing from trunk. You are forced to move forward and fix
> > new regressions in trunk to release to the store (thus your fix for the test
> > is not a patch, but a whole new version). This is the source of issues with
> > calendar in this specific case.
> Yeah, click releasing follows what daily release used to do; then came
> the train.
>
> I don't follow the rest, are you proposing that all projects decouple
> their tests from trunk? How can you provide traceability; like run the
> tests for version 1 instead of version 2 which may have an sdk change
> in between? Or do you always want to run the latest tests for whatever
> package?
I wrote this a bit quickly so forgive me. I wasn't trying to propose 
anything; at least not via this email. However, we should talk, so let's 
put something on the calendar :) I'll put together a request.

I was trying to point out a few things with regards to how we are 
handling regressions. And I wanted to also point out what happened in 
this case so Dimitri and everyone else could understand the facts. When 
these regressions pop up in the trunk version of an application it 
blocks the ability to release any code, including code to fix other 
issues inside the image itself. This sounds more confusing than it is.

As an example, the calendar blockage on the latest image has a few tests 
that started failing after 5.2 landed. You've seen the landing emails 
with this snippet;

* flaky test failure on calendar-app (Alan/Jean-Baptiste):
https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1293489

To fix you pull calendar trunk and investigate the tests. But wait, you 
find out there's a regression caused by qtorganizer that causes calendar 
trunk to be broken. Now before you can fix the image blocker, you need 
to fix the calendar app trunk. In the meantime nothing can land in 
calendar trunk, and no fix can land in the image. Repeat for each 
regression you find while stabilizing trunk and you can understand the 
source of the delays.

Nicholas