On Fri, 2016-08-19 at 14:11 +0000, Michael Terry wrote: > OK, maybe I was overly grumpy last time I commented, I didn't mean to > sound hostile. > > --- > > As for the autopkg tests, you're right that building the package is > something. > > But one of the goals of a MIR is to ensure that packages are well > maintained. And letting the integration tests bit rot for six months > is > not a great sign. > > Ideally either the unity-scope-click maintainers would have gone down > a > stack and committed to fixing the harness or applied enough pressure > to > the harness maintainers to commit to fixing it. > > Neither happened, which is why I'm a touch worried that we'll never > get > to the point of turning the integration tests back on, simply because > no > one is working on it. > > Can you commit to putting resources into it or find someone that can? > According to the bug it's easy to reproduce. Just a little hard to > fix.
I can't personally commit to it, but I've asked if someone more knowledgeable of the python test harness code than I am, could be scheduled to look at it. Hopefully it turns out to be an easy fix. > --- > > As for the database, yes an sqlite database isn't quite as bad as an > executable blob sitting there. > > Someone *could* generate the same database, *if* they knew which > locales > were specified on the command line *and* what clicks were installed > on > the system at the time (right, it pulls list of clicks from the > installed set?). > > At a minimum, I'd like to see some documentation. Like a README > saying > "install latest Touch image and run 'init-departments my.db en_US > zh_CN > fr_FR' to get this same db". > > But what I'm trying to get at is, can we make it more generate-able? > Like... Can we hardcode the list of clicks and just grab those > translations from the store? It doesn't solve the fact that we need > to > hit the network for translations, so we still can't generate the db > at > build. But at least it could be generated straight from a built tree > rather than having to set up a separate Touch system. No I don't think we can make it easier to generate the db at build. The database doesn't need to be re-generated cleanly every time either, so there isn't a need to set up a BQ phone image to run it on. There is a README in the sub-directory for the tool in the source tree, which states how to call the command. I don't know that we'll have time to make this better for yakkety release, but there are a few bugs about the init-departments tool filed, and as many of the assertions about how we need to handle departments are no longer valid (and we won't really be supporting clicks on yakkety+ anyway), what we really want to do here is just get rid of the tool and thus the pre-seeded cache completely. There's some higher priority work than trimming that fat at the moment though, like fixing the scope so that we can launch apps from snaps instead of just clicks. As soon as yakkety-proposed clears up and I can get those bits finished, I might have some more time to poke at the lower hanging fruit of removing that database and just including the translations locally. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1614203 Title: [MIR] unity-scope-click To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1614203/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
