If you wanted to write a QML / Ubuntu SDK application but had a considerable amount of python3 code that you didn't want to throw out the window you can find pyotherside utterly fantastic.
In short, you add one .so file (105K on amd64) (or install it system-wide) run qmlscene on your qml stuff and you can import and call anything from python world and get an asynchronous response. You can also use QML signals. This works pretty much like magic, it's speedy, responsive and the code is tiny. If you ever looked at pyside or pyqt then this is everything but.
I strongly recommend watching the Qt Developer Days 2013 presentation by the upstream author. You should also keep a look at the documentation. I've filed an ITP (to get it packaged in Debian) and we should see it in Debian and Ubuntu very very soon.
The upstream git repository has a number of examples. I love the matplotlib example that shows how you can render arbitrary bitmaps and push them to QML trivially.
If you want to give it a try Ive prepared a PPA with the same packages that I uploaded to Debian. Give them a spin and let me know if you find any problems.
Wednesday, April 30, 2014
Friday, April 11, 2014
Checkbox challenges for 2015
Having a less packed day for the first time in a few weeks I was thinking about the next steps for the Checkbox project. There are a few separate big tasks that I think should happen over the next 6-18 months.
First of all, our large collection of tests needs maintenance. We need to keep adapting it to changing requirements and new hardware. We need to fix bugs and make it more robust. We also need to add some level of polish to the user interface. To make sure all our test programs are behaving in an uniform way, use correct wording, can be localized, etc. Those are all important to keep the project healthy. We also have a big challenge ahead of us, with the whole touch world entering the Ubuntu ecosystem. We will have to revisit some decisions, decide which libraries, tools and layers to use to test certain features and make sure we don't leave anything behind. This is very challenging as we really have a lot of existing tests. We also need to make them work the same way regardless of how they are started (classic Ubuntu, touch Ubuntu, remote Ubuntu server).
The core tools got an amazing boost over the past 12 months. Starting from pretty old technology that was very flexible but hard to understand and modify to something that is probably just as flexible but far easier to understand and work with. Still, it's not all roses. The Ubuntu SDK UI needs a lot of work to get right. It has usability issues, it has architecture design issues. We also have a big disconnect between the core technology (python3) used by and Qt+QML C++ codebase, talking over D-Bus with the rest of the stack. That brings friction and is 10x harder to modify than an all-python solution. Ideally we'd like to switch to PyQt but how that fares with the future Touch world is hard to say. I suspect that our remote testing story will help us have a smooth transition that won't compromise our existing effort and equally won't collide with the direction set by the first Ubuntu touch release.
Perhaps not in the spotlight but definitely we need to work on "whitelists" (aka test plans). We need to learn how our users take our stack and remix it to solve their problems. Our test plan technology is ancient and shows its weaknesses. We need a 2.0 test plans that allow us to express the problems we need to solve clearly, unambiguously and efficiently. We need to improve our per-device-instance test support. We need to provide rich meta-data for user interfaces. We need better vocabulary to create true test plans that can react to results in a way unconstrained by the design of the legacy checkbox first written over seven years ago. We also need to execute those changes in a way that has no flag days or burnt bridges. Nobody likes to build on moving sand and we're here to provide a solid foundation for other teams at Canonical and everyone in the free software ecosystem.
Lastly we have the elephant in the room called deployment. Checkbox doesn't by itself handle deploying system images and configuration onto bare metal (we have a very old and support project for doing that) and the metal is changing very rapidly. Severs are quite unlike desktops, laptops (Ethernet-less ultrabooks?) and most importantly tablets and the whole touch-device ecosystem behind them. In the next 12 months we need a very good story and a solid plan on how to execute the transition from what we have now onto something that keeps us going for the next few years, at least. Canonical luckily has such a project already, MAAS. MAAS was envisioned for big iron hardware but if you look at it from our point of view we really want to have uniform API for all hardware. From that big-ass server in a Data Centre somewhere across the globe to that development board on your desk, which will be the next tablet or phone product. We want to do the same set of operations on all of the devices in this spectrum, manage, control, track, re-image. The means and technology to do that differ widely and from experience I can tell you this is a zoo with all the queer animals you can think of but I'm confident we can make it work.
So there you have it. Checkbox over the next 12+ months, as seen through my eyes.
First of all, our large collection of tests needs maintenance. We need to keep adapting it to changing requirements and new hardware. We need to fix bugs and make it more robust. We also need to add some level of polish to the user interface. To make sure all our test programs are behaving in an uniform way, use correct wording, can be localized, etc. Those are all important to keep the project healthy. We also have a big challenge ahead of us, with the whole touch world entering the Ubuntu ecosystem. We will have to revisit some decisions, decide which libraries, tools and layers to use to test certain features and make sure we don't leave anything behind. This is very challenging as we really have a lot of existing tests. We also need to make them work the same way regardless of how they are started (classic Ubuntu, touch Ubuntu, remote Ubuntu server).
The core tools got an amazing boost over the past 12 months. Starting from pretty old technology that was very flexible but hard to understand and modify to something that is probably just as flexible but far easier to understand and work with. Still, it's not all roses. The Ubuntu SDK UI needs a lot of work to get right. It has usability issues, it has architecture design issues. We also have a big disconnect between the core technology (python3) used by and Qt+QML C++ codebase, talking over D-Bus with the rest of the stack. That brings friction and is 10x harder to modify than an all-python solution. Ideally we'd like to switch to PyQt but how that fares with the future Touch world is hard to say. I suspect that our remote testing story will help us have a smooth transition that won't compromise our existing effort and equally won't collide with the direction set by the first Ubuntu touch release.
Perhaps not in the spotlight but definitely we need to work on "whitelists" (aka test plans). We need to learn how our users take our stack and remix it to solve their problems. Our test plan technology is ancient and shows its weaknesses. We need a 2.0 test plans that allow us to express the problems we need to solve clearly, unambiguously and efficiently. We need to improve our per-device-instance test support. We need to provide rich meta-data for user interfaces. We need better vocabulary to create true test plans that can react to results in a way unconstrained by the design of the legacy checkbox first written over seven years ago. We also need to execute those changes in a way that has no flag days or burnt bridges. Nobody likes to build on moving sand and we're here to provide a solid foundation for other teams at Canonical and everyone in the free software ecosystem.
Lastly we have the elephant in the room called deployment. Checkbox doesn't by itself handle deploying system images and configuration onto bare metal (we have a very old and support project for doing that) and the metal is changing very rapidly. Severs are quite unlike desktops, laptops (Ethernet-less ultrabooks?) and most importantly tablets and the whole touch-device ecosystem behind them. In the next 12 months we need a very good story and a solid plan on how to execute the transition from what we have now onto something that keeps us going for the next few years, at least. Canonical luckily has such a project already, MAAS. MAAS was envisioned for big iron hardware but if you look at it from our point of view we really want to have uniform API for all hardware. From that big-ass server in a Data Centre somewhere across the globe to that development board on your desk, which will be the next tablet or phone product. We want to do the same set of operations on all of the devices in this spectrum, manage, control, track, re-image. The means and technology to do that differ widely and from experience I can tell you this is a zoo with all the queer animals you can think of but I'm confident we can make it work.
So there you have it. Checkbox over the next 12+ months, as seen through my eyes.
Friday, April 4, 2014
Checkbox Project Update
The Checkbox project is undergoing more changes. We had to solve the problem of bug management and feature tracking for releasing each of the many components that now make up the project. We have discussed a number of ideas, including using tags, milestones, series and lastly, to use multiple projects. Using multiple projects ended up the most direct and effective option.
We had to add a twist to that idea though, apart from the existing checkbox project, all of the new projects would have no source. Just bugs, blueprints and releases (series, milestones and tarballs). Why? Because we lead a double life and need to take that into account and splitting the project into multiple code repositories is a separate transition that we have decided not to do (at this time, though I think that's healthy for us).
So the double-life aspect. As mentioned in one of my earlier posts, Chcekbox has two kinds of releases. The one life is about our upstream role. We release tarballs, package them for Debian, get them sponsored, synchronize them to Ubuntu into the hands of everyone using the platform. The other life is organized around our PPAs, internal customers and project schedules. There Ubuntu deadlines don't matter but it also means that important bugs have two releases they are a part of. They are a part of one (or more) of the upstream components. This is important so that we can properly document what goes into each release. They are also a part of a timestamped delivery for our internal customers. They also care about tracking fixes to the issues blocking their work.
So with that we now have checkbox-project (a launchpad project group) that aggregates our entire stack. You can now see all of the bugs and milestones throughout the project. You can also see how particular bugs or features translate to upcoming, scheduled releases of particular components. We hope that this new arrangement will be more valuable for everyone who tracks our work, despite the added set of project.
We had to add a twist to that idea though, apart from the existing checkbox project, all of the new projects would have no source. Just bugs, blueprints and releases (series, milestones and tarballs). Why? Because we lead a double life and need to take that into account and splitting the project into multiple code repositories is a separate transition that we have decided not to do (at this time, though I think that's healthy for us).
So the double-life aspect. As mentioned in one of my earlier posts, Chcekbox has two kinds of releases. The one life is about our upstream role. We release tarballs, package them for Debian, get them sponsored, synchronize them to Ubuntu into the hands of everyone using the platform. The other life is organized around our PPAs, internal customers and project schedules. There Ubuntu deadlines don't matter but it also means that important bugs have two releases they are a part of. They are a part of one (or more) of the upstream components. This is important so that we can properly document what goes into each release. They are also a part of a timestamped delivery for our internal customers. They also care about tracking fixes to the issues blocking their work.
So with that we now have checkbox-project (a launchpad project group) that aggregates our entire stack. You can now see all of the bugs and milestones throughout the project. You can also see how particular bugs or features translate to upcoming, scheduled releases of particular components. We hope that this new arrangement will be more valuable for everyone who tracks our work, despite the added set of project.
Wednesday, April 2, 2014
PlainBox Target Device
The plainbox-0.6 milestone is full of content but one thing I want to point out is the CEP-4 blueprint. In short, you will be able to run PlainBox on a desktop or laptop computer but execute tests on a server or tablet device you can connect to over ssh or adb.
I'd like to solicit comments and feedback on the proposed design. Development has started but so far just in R&D mode, to check the limitations of adb and see how the proposed design really fits into the current architecture.
So, if you are interested in device or server testing, have a look at the specification (linked from the blueprint) and discuss this in checkbox-dev@lists.launchpad.net. Please help us help you better.
Subscribe to:
Posts (Atom)