ubuntu-phone team mailing list archive

[Sergio Schvezov <sergio.schvezov@xxxxxxxxxxxxx>]

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

> 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?

>> Auto landing of clicks is not done as there is no testing along the
>> pipeline for clicks; merge requests, test the debs, most devs test
>> trunk (which doesn't include launching in a confined environment) or
>> use qt creator which when ran also doesn't run under confinement.
>>
>> The last bastion, which would solve almost any issue with this is to
>> add a testing instance after the clicks build, ci told us end of March
>> for it to be done; so waiting for that moment.
>>
>> For auto uploads we also need the data to be parsed from the click on
>> upload instead of filling forms (version, arch, framework, changelog).
>
> +1 on this, mistyping a version turns into a big mess for the person who
> does it .Sergio and I both have experience in this.
>
>
> Nicholas