On Thu, Mar 20, 2014 at 3:49 PM, Nicholas Skaggs <[email protected]> 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 -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
