Posts tagged with 'community'

There’s been a lot of talk about the Ubuntu Edge, and our associated Indiegogo campaign to fund it. There has been a lot of positive coverage on news sites, social media, Reddit and even one television interview. But there have also been a lot of questions about why we’re doing this, and why we’ve chosen a crowd-funding campaign to do it. Since I’ve seen so many of the same questions being asked by so many people, I wanted to take the time to try and explain things a little bit better.

What it isn’t

In order to fully understand and appreciate what the campaign is about, it might be easiest to first explain fully what it isn’t. Once we’ve done away with these misconceptions, it should become more clear why it is what it is, and finally why that is important.

First of all, and perhaps most importantly, this is not a charity. We have provided a $20 perk for people who want to see this campaign succeed but don’t have the means or desire to purchase one of the Ubuntu Edge devices. But this is primarily a way for people to get very high-end hardware by paying for it’s creation. I don’t have the exact numbers, but just going by what we’ve seen of the perks claimed, people have been contributing at levels that would get them a phone more than 3.5 times more often than the much less expensive founder’s perk. This tells me that people aren’t supporting this campaign because they think it’s a good cause, or because they like what Canonical is doing, by and large they are supporting this campaign because they want an Ubuntu Edge in return.

Secondly, and this is one that has been asked a lot, this is not a financial investment. OEMs aren’t stupid, venture capitalists aren’t stupid, and Mark Shuttleworth isn’t stupid. If there was money to be made in building bleeding-edge phones then we would have half a dozen to choose from at our local store. The margins on hardware sales is much lower than many people realize, and without a high rate of profits available, only a very low level of risk can be assumed. That’s the main reason nobody else has built a phone like the Ubuntu Edge, and why nobody is going to anytime soon if we were to try and do it using capital investments. The Ubuntu Edge doesn’t need to prove that people want scratch-proof screens or high-capacity batteries, it doesn’t need to prove that consumers like more power and more storage, it needs to prove that those technologies are ready to be produced in high volumes without supply or manufacturing problems. It doesn’t need to prove that people want a desktop available at home or work, but it does need to prove that the hardware and software are capable now of providing that convergence in a satisfactory way that previous attempts couldn’t.

Finally, it’s not a way of making money for Canonical or a last-ditch effort for keeping either Ubuntu or Ubuntu Touch alive. Whether this campaign succeeds or fails, we will continue to work with OEMs to bring multiple consumer phones to market, most likely using slightly better hardware than the current generation of smart phones, where there is little risk involved on the hardware side. But in order for Ubuntu to provide the kind of convergence and one-device experience that we envision, we needed skip the slow, safe evolution of hardware and spark the flames on a whole new class of phone. So while we work on getting Ubuntu phones to market with our partners, the Ubuntu Edge will provide the seeds for the suppliers and manufacturers that those partners use, so they will be ready to build their new generation of superphones when the time comes.

What it is

Now that I’ve gone over what this campaign isn’t, let talk about what it is. I spent some time over this weekend thinking about how to accurately describe it without going deep into the economics or politics of it, trying to find parallels in other industries (like Mark’s F-1 analogy) that wouldn’t fall apart when going into the specifics of either. In the end, I decided that the thing this campaign resembles the most is an adventure.

Now that’s vague, I know, so let me give some more concrete examples. I liked Mark’s F-1 analogy, but when looking into how F-1 actually operates these days it really doesn’t quite fit. Instead it’s more like X-Prize competition that put the first private manned vehicle into space. Even though there was a monetary prize in that competition, it was only a tiny fraction of the money that went into building any of the entrants. The reason anybody participated was to push the bounds of technology and to try and birth a new industry, one where they would stand to benefit more in the long run than any possible profits they could have made by sticking with the status quo.

But those initiatives were largely funded by wealthy individuals, who probably didn’t expect to get much in return. So for a more fitting analogy we need to go a bit further back in time, to expeditions into the Americas and Africa, some of which were funded only by those who were to participate in them, and who could expect little more than the thrill of participating. While not pushing the limits of technology, these adventurers would certainly push the bounds of knowledge to new levels, and would fundamentally change the way the world looked.

[Update] It has been pointed out in the comments that many of these expeditions had either deplorable intents or disasterous consequences for the native people. While this was not at all what I had in mind, I understand that my knowledge of those histories is largely influenced by my own ancestry. A better example, as also pointed out in the comments, would be the expeditions to both the north and south poles, or the scaling of Everest.

Why it’s important

Now both of these are extreme examples, and certainly far outshine what we’re trying to do with the Ubuntu Edge. It is just a computer after all. But on a smaller scale the reasons and motivations are the same, there is a desire to push the limits that currently confine us. And that’s certainly not a feeling that’s limited to Canonical, over 15,000 people have contributed to the campaign in one way or another, and around 10,000 have committed to sharing the adventure with us from the beginning by claiming their own phone. These aren’t wealthy investors looking to become more wealthy, nor is it good-hearted folks who are giving us money just to be nice, these are thousands of people who want go on the adventure because it’s exciting, because it’s audacious, and because it gives them the future they want to see made.

So there it is, we’re embarking on an adventure, and we want you to come with us. If the Ubuntu Edge makes you excited for the future of computing, if you’re eager to see that future technology years before it becomes common place, if you want be on of the ones cutting new trails rather than following those well-worn paths cut years ago, then I invite you to sign up and add your name to the list of technology pioneers.

So you may have heard (seriously, how could you not?) that Canonical is crowd-funding a showcase phone called Ubuntu Edge. This is very exciting for a number of reasons, which I will get to below, but first go look at the Indie GoGo campaign page to see what I’m talking about.

Back? Good. Did you contribute? For the first 24 hours you can get a phone for a highly discounted contribution of $600 USD, rather than the $830 USD it will cost you tomorrow, so if you really want one of these it’s best to put your money on the table now.

Hardware Innovation

The phone hardware is impressive on it’s own, with more CPU, RAM and storage space than the laptop I was using for daily work last year. Not only that, but it’s going to feature advances in the glass and battery that I haven’t seen on other phones. Sapphire crystal glass, which can only be scratched by diamond, will keep your screen looking brand new for years to come. And the silicon-anode battery promises faster charging and longer runtime without increasing the size of the handset. You can see the full spec list on our other announcements.

I like this because we’re not asking you to contribute to making just another ordinary phone like all the rest you can buy already. Instead we’re pushing the envelope to pioneer a new class of convergent superphones, a market that Ubuntu is uniquely positioned for. This hardware will run Ubuntu Touch, Ubuntu for Android, and (when docked) a full Ubuntu Desktop. But we’re not just playing the “make it bigger, make it faster” game, the design of Ubuntu Edge’s hardware is deliberate, everything choice was made based on what would provide the best user experience, what would make the edge-swipe gestures easy and responsive, what would let us show more of an app’s content while still fitting into the palm of the user’s hand. This is a device designed from top to bottom for Ubuntu.

The margin on most production phones is thin enough to see though, which means that an OEM can’t afford to take risks with emerging technology or markets. That’s why it’s so important that we prove both the capabilities of Ubuntu for convergence, and the consumer appeal for such a device. Apple had to do it with the original iPhone, Google does it with their Nexus line of devices, and now it’s our turn to show what’s possible.

Community Campaign

Instead of seeking private capital to build these phones, then trying to sell them (at a profit or loss), we’ve decided to take it directly to the user community, which is why we’re asking you to pledge some amount to our campaign. We couldn’t build Ubuntu without our community, and we can’t build Ubuntu Edge without you either.

Our target goal is $32 million, which sounds like a lot, but only because it is. It really is. But it’s still only a fraction of the cost of an actual production line of phones. In order for an OEM to ship an Ubuntu phone (or any new phone), they would typically invest multiple times this amount. So as big as our target goal is, and I don’t think anybody’s crowd-sourced more, it’s certainly not an unreasonable amount for what we’re offering.

The target amount will allow us to manufacture just 40,000 handsets, most of which I would imagine will already be claimed by those contributing $830 or more (only $600 if you do it the first day!). All of the money raised in this campaign will go directly towards manufacturing and shipping these devices, it won’t be used for other Canonical business or even future Ubuntu development. When you do the math, which I did, you see that it comes out to $800 per device to manufacture, and we’re only asking for $830 to get it (again, in the first 24 hours, you can get it below that cost). This is an effort to build a new class of superphone, not a way of making Canonical rich. If we reach our goal, you should have your Ubuntu Edge in hand sometime in May 2014!

Non-monetary contributions

I know that $830 is a lot of money, even $600 is a lot of money, but those aren’t the only ways you can help. In addition to giving smaller amounts in support of this campaign (for which there are other perks) you can help make it a success by spreading the word. No doubt it will be picked up by the usual online news sources, forums and blogs but let’s break it out of our usual Linux/FLOSS sphere.

So share links to the Indie GoGo campaign page on Facebook, Twitter and Google+. Tell your friends, especially any tech savvy ones, about it. Send an email to your local newspaper, radio or television stations, you never know who might think it’s an interesting story (and wouldn’t you just love to see Ubuntu on TV?). Every person you tell about the campaign brings us one step closer to reaching our goal, and it doesn’t cost you a penny.

We’ve had a great week running the Ubuntu Core Apps Hack Days so far, we’ve seen several new contributors join our development teams, and lots of merge proposals coming in and landing. But we’re not done yet, we’ll be in #ubuntu-app-devel again today from 9am to 9pm UTC to help anybody who is interested in getting started contributing to these apps.

Today we’ll be focusing on an app that may not be high on the average user’s list of mobile apps, but is indispensable for anybody working on a ported image or writing an app for Ubuntu Touch, that is the File Manager App!

Thanks to reusing the Folder List Model QML Plugin from the Nemo Mobile project, the File Manager developers were able to get a very functional application working in a very short amount of time. That means that our dogfooding list is already complete!

Browse folders. DONE!

View files within folders. DONE!

View file information. DONE!

Copy files. DONE!

Delete files. DONE!

Move files. DONE!

But don’t let that list fool you, there’s still plenty of work to be done. The biggest one is making sure that any changes we’ve made to the Nemo plugin are sent back upstream. If anybody from the Nemo project can help us with this, please find me (mhall119 on IRC). We also need to make sure we have full Autopilot test coverage, and fix any remaining bugs that have been reported.

I hope you all enjoyed spending some time playing Sudoku yesterday, because we’re back to work again for another Ubuntu Core App Hack Day! As always you can find us in #ubuntu-app-devel on Freenode IRC from 9am to 9pm UTC to answer all of your app hacking questions, help get you setup and started contributing, or just generally discuss how to write Ubuntu Touch apps in general.

Today we leave behind yesterday’s light hearted fun and games and turn to the (only slightly) more serious work of reading news with the RSS Reader app! Another one of the original Core Apps, the RSS Reader got some unexpected designs from the Canonical Design team that converted it from the typical list-of-headlines to a beautiful organic grid seen here.

Because of these very recent and very major changes to the UI, there’s a lot of work to be done to get all of the previous functionality working again at the same level. For dogfooding the RSS Reader, these are our goals:

Add a feed.

Browse feeds. DONE!

View a feed.

Select an item to view from within the feed.

Because of the major changes, this app can use a lot of help from people who are simply willing to use it and report bugs so that the developers (and all of you new contributors) have a list of things to work on. Then we need you QML/Javascript hackers to pick things from that list and start making and submitting your fixes. Finally we need Autopilot tests written or updated for this new look, so I’m looking at you Python guys and gals to lend us a hand too.

We’re continuing our Ubuntu Core Apps Hack Days again today in the #ubuntu-app-devel channel on Freenode IRC, from 9am to 9pm UTC. If you want to learn more about the Core Apps and how you can get involved, jump into the channel and give myself (mhall119), Alan Pope (popey) or David Planella (dpm) a shout.

We’ve been working hard on the Core Apps lately, which is why I’m glad that today we get spend time on something a little more fun: the Sudoku App! Sudoku was originally developed outside of the Core Apps umbrella, but it progressed so quickly and fit Ubuntu Touch so well, that we invited it’s developer to join the rest of our Core Apps.

Sudoku was so far along before joining the Core Apps, that our dogfooding list was already largely complete:

Start a new game DONE!

Record and display game statistics DONE!

Provide hints DONE!

But even as complete as it is, there are still a few bugs to squash and some final Autopilot tests to write, so if you have QML and Javascript skills or Python skills and can spare a little bit of your time, you can help us put the finishing touches on this classic game. And if you want to help us, you know, “test” it for a few hours of your day, we’ll totally consider that a contribution too.

It’s day 5 of the Ubuntu Core Apps Hack Days! We’ve seen a tremendous amount of work coming into the Core Apps, and have several new contributors joining the initiative. We’re keeping that momentum going throughout the week in #ubuntu-app-devel on Freenode from 9am to 9pm UTC, so come and be a part of this exciting project.

Today we’ll turn our attention to the Weather application, another one of the original Core Apps, and another one that is already largely complete. The Weather app gained multi-city support and a long range forecast early on, and has more recently added the ability to toggle between Celsius and Fahrenheit temperature displays. Between those, it met all of the criteria we set for dogfooding:

Choose a location to view weather from. DONE!

View current weather conditions. DONE!

View a 10 day forecast. DONE!

Configure C or F and display that chosen setting for all locations. DONE!

Since the features are complete, we now need to put the rest of our effort towards polish and quality. This means we need those of you with QML and Javascript knowledge to help fix the reported bugs in Launchpad, and those of you with Python knowledge to help us finish the Autopilot test coverage, so that we can make this app rock solid and reliable for every day use.

Welcome back to another week of Ubuntu Core Apps Hack Days! As always we will be in #ubuntu-app-devel on Freenode’s IRC from 9am to 9pm UTC to answer all of your questions, help you get your development environment setup, and get started contributing to the Core Apps projects.

To start off this week we will be taking a look at the Calculator app. The Calculator was another one of the original core apps, made some of the fastest progress and was one of the first to make it onto the device images’ default install. The Calculator is as simple as it is beautiful, and thanks to this and the hard work put in by it’s developers, that means it’s already feature-complete as far as our dogfooding list was concerned:

But even though the main features are complete, there is still some work left to be done. Most importantly, with Ubuntu’s focus on quality these days, we need to finish up our Autopilot test coverage, which means we need the help of all your Python developers out there. We also have a list of reported bugs that need to be fixed, which is going to require somebody with QML and/or Javascript knowledge. If either of those suits you, please join us in #ubuntu-app-devel today to get started!

Today is the last Ubuntu Core Apps Hack Day of the week, but don’t worry because we’re coming back every day next week to cover more of our amazing Core Apps. Like previous days, we’ll be in #ubuntu-app-devel in Freenode IRC from 9am to 9pm UTC to help you get setup and contributing to these apps.

Today our focus will be the Clock app, one of the original Core Apps, and while you might think that a clock app would be simple, there’s a lot going on in this one. In addition to showing you the current local time, the Clock app also sports a world clock, a timer, a stopwatch, and soon the ability to set alarms. Our dogfooding goals for the clock are:

View local time. DONE!

View times in different cities. DONE!

Stopwatch (start, stop, pause, lap) DONE!

Set alarm, be notified when the alarm time arrives

Set timer, be notified when the time runs out

As you can see, the first 3 are already done and working. The remaining two are blocked on platform work for setting alarms that will be triggered by the system even when the Clock app itself isn’t active.

But that doesn’t mean there’s nothing for new contributors to do. One of the Clock’s most active developers, Nekhelesh Ramananthan, has helpfully provide me with a list of things that he needs your help with:

Getting autopilots tests ready for the timer, stopwatch and clock

Bug fixes for timer, clock and world clock

Caching support for sunrise/sunset times. The sunrise/sunset should only be retrieved once a day or when the location is changed. I will create a bug report to track this and also tag it hackday.

He even went so far as to tag bugs that would make good hack day targets and provide some insight into how to solve them, so you can go grab one from this list and give it a shot. Some of these will require QML and Javascript knowledge, others are for needed Autopilot tests that need Python, so we’ve got something for everybody. Nekhelesh (nik90) will also be in the IRC channel tomorrow to help you work on these items and review your contributions.

Today we’re going to turn our attention to the Music app. This app is a little bit different in the fact that it didn’t start off as a Core App, or even as a single app. Several people had started on music apps or mockups for music apps, so we brought them together to combine their efforts into a single app. Because of this, instead of progressing through the usual steps of defining requirements, designing user experience and then implementing features, we had all three things coming together at the same time. This put the Music app both ahead and behind the others in different ways.

The feature targets we set out for dogfooding the Music app are all larely half-done, as a result of how the app is the amalgamation of several formerly independent efforts. You’ll find that many of them are complete on the back-end but need to be integrated with the new front-end work, or vice-versa. As such, this is a project where a little bit of effort can make a very large impact. To get the Music app ready, we want to get the following working:

Read in music from ~/Music.

Browse a list of artists.

Browse albums by an artist.

Browse songs by an artist.

Play a song, with transport controls (Play, Stop/Pause, Skip Back/Forwards).

Shuffle.

Bonus: pull in album cover/details from the net.

To do these, you’ll need some working knowledge of QML and Javascript. The Music app also re-uses the File Manager App’s plugin to find and read metadata of music files, so if you have C++ experience there are things you can work on there too. And of course our Python developers can help by working on Autopilot tests to make sure that the above features work (and continue to work) as expected.

Just like the Calendar app, there are some things that we want the Music app to do that require work to be done on the platform side. Specifically, we want the Music app to continue playing songs when you switch away from it or turn off the phone’s screen. Currently the platform will suspend the Music app’s process when this happens, so playback stops. However Canonical’s Jim Hodapp, who has already done a lot of work on multimedia integration and gstreamer, will soon begin work on a system-wide media playback service that the Music app will be able to hand songs off to. Until then we will continue using the Qt Multimedia APIs to play songs while the application is still active.

Today is the first of the Ubuntu Core Apps Hack Days, where we will focus on one app per day to help get new contributors setup, walk people though installing and testing the Core apps, filing bug reports and knocking out some of the outstanding feature requirements needed to get the Core Apps ready for release.

The Hack Day activity will happen in the #ubuntu-app-devel channel on Freenode IRC. We will have dedicated helpers (myself, dpm and popey) from 9am to 9pm UTC to answer your questions, help get your setup, and review your code. We will also have developers of the Core Apps themselves joining the channel as they can to help with your contribution.

Today we’re going to be focusing on the Calendar application, one of the original Core apps and also one of those that is already in the default device images. Our goal for today is to get the Calendar ready for every-day use (dogfooding), which means we need to get the following features working:

Browse by month

Browse by week

Browse by day

Bonus: sync Google Calendar

To help with these, you’ll need to know some QML and/or Javascript. You can read through our Core Apps Development Guide to get started.

In addition to these required features, we also have a load of new designs to improve the functionality and user experience for the app. If you’re feeling like taking on a slighter larger task, and you have a good handle on building front-end functionality in QML, here’s a good opportunity to leave your mark.

We also want to fill out our automated test coverage, of which there are currently five bugs that need somebody to work on them. Autopilot tests are all written in Python, so this is a great way for our large community of Python developers to get involved with the Core Apps projects.

This is my third Core Apps update, you can go back and read about the Clock and Calendar apps if you missed them. Today I’m going to show off the Calculator app.

Calculator Features

Basic Functions

The Calculator does exactly what you would expect a calculator to do. It’s a four-function calculator and does it’s job perfectly well. But it has a few unique features that make it so much more useful. Using the old paper-roll calculators as inspiration, the calculator lets you label the numbers in your calculation, so you can go back and see “7 what?”. When you’re done with a calculation, instead of clearing it off, you simply drag upwards to “tear off” that individual calculation.

Calculation History

Just because you’ve torn off a calculation, doesn’t mean you’ve thrown it away. Instead, your calculation is stored in a browseable history. This makes the labels even more useful, because you can go back hours, days, even months to an old bit of calculating. You can even tap on any number in any of those calculations to insert it into your current one. If you really are done with a calculation, you can swipe it to the right or left to delete it from your history.

Visual Designs

The Design team says we’ll have visual designs for the Calculator later this week, so the developers will be able to start on implementing those. Keep an eye on the design team blog and Google+ to see them when they come out.

Release Schedule

The release schedule for the Calculator is the same as the Clock. It’s already well past what would be considered an Alpha release, so we just called May for that milestone. Going forward, we plan on delivering a Beta in July that includes the visual designs, followed by a final release in August.

Yesterday I posted the first in a new series of Core App Update, featuring the Clock App’s development. Today I’m going to cover the status of the Calendar

Calendar Features

Calendar View

The calendar now provides several different views you can choose from. You start off with a full month at the top, and your events for the day below. Swiping left and right on the month will take you back or forward a month at a time. Swiping left or right on the bottom half will take you back and forward a day at a time.

Pull the event area down and let it go, and the month will collapse down into a single week. Now swiping left and right there will move you back and forward a week at a time. Pull down and let it go again and it will snap back to showing the full month.

Finally, you have an option in the toolbar (swipe up from the bottom edge) to switch from an event list to a timeline view of your events.

Adding Events

You can current add events to the calendar app, and they will be stored in a local database. However, after discussions with Ubuntu Touch developers, the Calendar team is refactoring the app to use the Qt Organizer APIs instead. This will allow it to automatically support saving to Evolution Data Server as a backend as soon as it’s integrated, making calendar events available to other parts of Ubuntu such as the datetime indicator. Being able to import your ical feeds is also on the developer’s TODO list.

Visual Designs

We don’t have new visual designs for the Calendar yet, but it is one of the apps that the Design team has committed to providing one for. Now that they are done with the Clock’s visual designs, I hope to see these soon for the Calendar.

Release Schedule

Once again I worked with the Calendar developers to set release targets for their app. The alpha release is targeted for month-2, this month, and should include the switch to Qt Organizer. Then we plan on having a Beta release in August and a Final in September.

The Ubuntu Touch Core Apps project is a new kind of collaboration between Canonical and the wider Ubuntu community, with a goal of developing high-quality applications for Ubuntu Touch. A couple of months ago I set out the Core Apps roadmap to October, and it’s high time I got around to giving you an update on our progress.

I had originally planned on giving an update of each of the core apps in a single blog post, but I realized that was going to get very, very long. And nobody has time to read a giant wall of text. So instead I’ll be breaking them up, one post per apps, so you can spread your reading time over multiple days.

To kick this off, here are the latest developments going on in the Clock app:

Clock Features

Sunrise & Sunset

Recently added to the main Clock tab is a way to check the sunrise and sunset times for the day. Simply tap on the clock face and it will switch to the sunrise/sunset view. Tap it again to switch back. Swipe up from the bottom to reveal the toolbar, where you can set your location (which is used to calculate your specific sunrise and sunset times).

Alarms

The Clock app developers are still waiting on a platform API to support registering alarms that will work even when the Clock app isn’t running. But while they’re waiting on that, they’ve still be working hard on the interface for managing your alarms. Their approach is both minimal and obvious, you drag the hour and minute hands around to the time you and and click Done in the center. If you need more options, you can pick how often to repeat, what alarm tone to use, and whether or not to vibrate.

Now these won’t actually work until the platform API is in place, but you can already see how it will look to the user, and how simple it is to do.

Timer

Like the alarms, setting a timer is both minimal and obvious. Unlike alarms, the timer is working today. Drag the hand around to set how many seconds, tap the minutes part of the time and drag the hand to set the minutes. Make more than one revolution around the dial and it will start adding hours as well.

Another nice feature is the ability to define custom timers that you can use again and again. Swipe up from the bottom to reveal the toolbar again, select Add Preset, and set the duration using the same simple dragging motions on the dial.

Stopwatch

Finally we come to the stopwatch part of the app. In addition to simple start, pause and reset functionality, the stopwatch lets you mark laps as it goes, and keeps a log of each one that you can view both while the stopwatch is running and after.

Visual Designs

Some of you may have seen the new visual concepts that the Design Team published last month, which received quite a bit of positive feedback. Well this week they sent the Clock developers the completed visual designs for the Clock app, so we should start to get our first taste of those designs in action in the next few weeks.

Release Schedule

Starting a couple of weeks ago, I started working with each of the Core Apps developer teams to set release targets for Alpha, Beta and Final releases of the app, with a goal to have them all at a 1.0 version before the October release of Ubuntu 13.10. For the clock, we decided to mark the month-1 milestone (May) as an alpha release, because of the progress they had already made. We then picked month-3 (July) for beta and month-4 (August) for our final release target. Furthermore we have work items assigned on a monthly release basis to track the progress we are making.

Packages

I quite like the current status of Qt 5 in Debian and Ubuntu (the links are to the qtbase packages, there are ca. 15 other modules as well). Despite Qt 5 being bleeding edge and Ubuntu having had the need to use it before even the first stable release came out in December, the co-operation with Debian has gone well. Debian is now having the first Qt 5 uploads done to experimental and later on to unstable. My work contributed to pkg-kde git on the modules has been welcomed, and even though more work has been done there by others, there haven't been drastic changes that would cause too big transition problems on the Ubuntu side. It has of course helped to ask others what they want, like the whole usage of qtchooser. Now with Qt 5.0.2 I've been able to mostly re-sync all newer changes / fixes to my packaging from Debian to Ubuntu and vice versa.

There will remain some delta, as pkg-kde plans to ask for a complete transition to qtchooser so that all Qt using packages would declare the Qt version either by QT_SELECT environment variable (preferable) or a package dependency (qt5-default or qt4-default). As a temporary change related to that, Debian will have a debhelper modification that defaults QT_SELECT to qt4 for the duration of the transition. Meanwhile, Ubuntu already shipped the 13.04 release with Qt 5, and a shortcut was taken there instead to prevent any Qt 4 package breakage. However, after the transition period in Debian is over, that small delta can again be removed.

I will also need to continue pushing any useful packaging I do to Debian. I pushed qtimageformats and qtdoc last week, but I know I'm still behind with some "possibly interesting" git snapshot modules like qtsensors and qtpim.

Patches

More delta exists in the form of multiple patches related to the recent Ubuntu Touch efforts. I do not think they are of immediate interest to Debian – let's start packaging Qt 5 apps to Debian first. However, about all of those patches have already been upstreamed to be part of Qt 5.1 or Qt 5.2, or will be later on. Some already were for 5.0.2.

A couple of months ago Ubuntu did have some patches hanging around with no clear author information. This was a result of the heated preparation for the Ubuntu Touch launches, and the fact that patches flew (too) quickly in place into various PPA:s. I started hunting down the authors, and the situation turned out to be better than I thought. About half of the patches were already upstreamed, and work on properly upstreaming the other ones was swiftly started after my initial contact. Proper DEP3 fields do help understanding the overall situation. There are now 10 Canonical individuals in the upstream group of contributors, and in the last week's sprint it turned out more people will be joining them to upstream their future patches.

Nowadays about all the requests I get for including patches from developers are stuff that was already upstreamed, like the XEmbed support in qtbase. This is how it should be.

One big patch still being Ubuntu only is the Unity appmenu support. There was a temporary solution for 13.04 that forward-ported the Qt 4 way of doing it. This will be however removed from the first 13.10 ('saucy') upload, as it's not upstreamable (the old way of supporting Unity appmenus was deliberately dropped from Qt 5). A re-implementation via QPA plugin support is on its way, but it may be that the development version users will be without appmenu support for some duration. Another big patch is related to qtwebkit's device pixel ratio, which will need to be fixed. Apart from these two areas of work that need to be followed through, patches situation is quite nice as mentioned.

Conclusion

Free software will do world domination, and I'm happy to be part of it.
Read more

I’ve blogged three times now, here, here and here, highlighting some of the apps being written with the Ubuntu SDK. Well after covering 44 of them, and more already popping up since yesterday’s article, we’ve decided that we need to start getting these into the Ubuntu Touch Preview images so that people can try them out on supported devices, give the developers real-use feedback and bug reports, and generally promote the amazing work being done by our community of app developers.

The Collection

So Alan Pope (popey) and I have kicked off what we’re calling the App Collection, which are apps being developed outside of the scope of our Core Apps project, but that we still want to support, promote, and guide through the process of getting them ready for deployment to Ubuntu devices. This means we’re going to commit to helping developers get their apps packaged, and we’re going to be uploading them to a new PPA specifically for these apps.

The Apps

We’re starting out by collecting a list of known apps, with information about where to find their source code, the status of packaging for the app, and finally whether they are available in the PPA or not. I seeded the list with the apps I’ve been blogging about, but it’s open to anybody who has an app, or knows about an app, to add it to this list.

Apps should be in a usable state before adding them to the list, and should perform a function that might be of interest to a user or tester. Hello World apps are great for learning, but it’s not really something that you want to promote to users.

Packaging

You don’t have to know about Debian packaging to get your app in our PPA, we’re going to help you bootstrap and debug your package. Our goal is to provide the minimal amount of packaging necessary for your app to be installable, on the desktop or on devices, and work properly. Of course, if you can provide packaging for your app, that will greatly speed up the process of getting it into the PPA.

We would also welcome any help from packagers. Even if you don’t have an app of your own, you can help support the app developer community by spending some time getting their packaging in order. QML apps are relatively simple when it comes to packaging, so a seasoned packaging veteran could probably knock one out in a matter of minutes.

PPA Review

You won’t have to conform to all of the requirements that you will to get into the Ubuntu archives, and there won’t be a lengthy review process. The Apps Collection is offered up for users to evaluate and test Ubuntu Touch and apps written for it, there is no guarantee of stability or security. Generally if it installs and runs, we’ll include it in the PPA. But we’re not crazy, and we won’t be uploading apps that are obviously malware or detrimental to the user or platform.

Preview Image Review

Your app will need to go through a more intense review before being approved to go into the default install of the Ubuntu Touch Preview. You code will be inspected by the engineers responsible for the preview images, to make sure it won’t cause any problems with stability or security that would interfere with the primary goal of the preview images, which is showing off the incredible user experience that Ubuntu provides on touch devices.

Inclusion

Once it’s ready, your app will join the default apps being developed by Canonical, as well as Core Apps being developed by other members of the community in collaboration with Canonical project managers, as part of the demonstration platform for Ubuntu Touch.

This is a great opportunity for you, as a developer, to get your app in the hands of a large number of early adopters. It’s also a great opportunity for us, being able to promote off our platform and how it is being used by the app developer community.

The excitement around the Ubuntu SDK and application development is still going strong, both on the Ubuntu Touch Core Apps side and with independent developers. So strong, in fact, that it’s time for another round of updates and spotlights on the work being done.

Core Apps in the Touch Preview

Some big news on the Core Apps side is that they are now being reviewed for inclusion in the daily Ubuntu Touch Preview images being developed by Canonical for the Nexus family of devices, and by community porters to a growing number of others.

Now that all of the Core Apps are being regularly built and packaged in the Core Apps PPA, they can be easily installed on desktops or devices. And, after being reviewed by the team building the Ubuntu Touch Preview images, three of them have been selected to be part of the default installed application set. So please join me in congratulating the developers who work to them.

New Independent App Development

In addition to the work happening on the Core Apps, there has been a continuous development by independent app developers on their own projects.

LoadShedding

Load shedding (or rolling blackouts) are a way for electricity utilities to avoid being overloaded by energy demands at peak times. This an be an inconvenience, to say the least, especially if you don’t know it’s coming. Maybe that’s why developer razor created this LoadShedding schedule app.

Multi-Convert

Multi-Convert was originally an Android application, written in HTML5, that is now being ported to Ubuntu. Multi-Convert allows real-time conversion of weight, length, area, volume and temperature between different standard units.

TV Remotes

I ran across not one, but two different apps for the remote control of home-theater-PCs, bringing the promise of your mobile phone as a “second screen” to Ubuntu Touch.

First is Joseph Mills (who also created a Weather app featured in the first of these roundups), with a remote control for MythTV:

And if you’re an XBMC user instead, not to worry, because Michael Zanetti has you covered with his remote control for XBMC:

CatchPodder

If you use your mobile device for listening to podcasts, you’ll be pleased to find the nice and functional podcast manager CatchPodder, which lets you subscribe to multiple feeds as well as playing files directly from the server.

AudioBook Reader

Keeping with the theme of listening to people talk on your Ubuntu device, we have an AudioBook manager and player that is being written with the Ubuntu SDK, which lets you load books, display cover images, and more.

Bits

If you’re a software developer, sysadmin or network engineer, there’s a good chance you’ve had to convert numbers between decimal, hexadecimal and binary. This makes Bits a very handy utility app to keep in your pocket.

Periodic Table

From the same developer who created a Software Center front-end and Pivotal Tracker (both featured in previous posts) has a new project underway, an element browser that gives you loads of detailed information about everything on the periodic table.

WebMap

Canonical engineering Manager Pat McGowan has gotten into the fun too, building an app for displaying web-based maps from a number of providers.

GetMeWheels

For Car2Go customers looking to rent or return a vehicle, GetMeWheels lets you easily find the nearest locations to you. Created by the same developer as the XBMC remote, this app was originally developed for Maemo/Meego, but is now being ported to the Ubuntu SDK.

PlayMee

A third app from the developer of GetMeWheels and XBMC Remote is PlayMee, a local music player that again was originally developed for Maemo/Meego, and is being ported to the Ubuntu SDK.

Tic-Tac-Toe

Tic-Tac-Toe is not a fancy game, but this one developed by Hairo Carela makes beautiful use of animation and colors, and even keeps a nice score history.

LightOff

If games are you thing, you should also check out LightOff, a simple yet challenging game where the object is to turn off all of the lights, but clicking one toggles the state of every square around it.

That’s all for now, keep those apps coming and be sure to post them in the Ubuntu App Developers community on Google+

It’s official, UDS 13.05 is coming up next month, marking our second online Ubuntu Developer Summit, and coming only two months after the last one. While going virtual was part of our transition to make Ubuntu’s development more open and inclusive, the other side of that coin was to start holding them more often. The first we put into affect in March, and the second is coming in May. Read below for information about this UDS, and changes that have been made in response to feedback from the last one.

Scheduling

The dates for UDS 13.05 are May 14, 15 and 16, from 1400 UTC to 2000 UTC. We will once again have 5 tracks: App Development, Community, Client, Server & Cloud and Foundations. The track leads for these will be:

App Development: Alan Pope, David Planella & Michael Hall

Community: Daniel Holbach, Nick Skaggs & Jono Bacon

Client: Jason Warner & Sebastien Bacher

Server & Cloud: Dave Walker & Antonio Rosales

Foundations: Steve Langasek

Track leads will be in charge of approving Blueprints and getting them on the schedule. If you are going to be responsible for running a session, please get with the track lead to make sure they have marked you as being required for that session. If you would like to get a session added for this UDS, you can do so either through registering a Blueprint or proposing a meeting through Summit itself. Both approaches will require the approval of a Track Lead, so make sure you discuss it with them ahead of time.

Changes to…

Using feedback from attendees of the March UDS, we will be implementing a number of changes for UDS 13.05 to improve the experience.

Hangouts

Google+ Hangouts have a limit of 15 active participants (if started with a Canonical user account, it’s 10 if you don’t have a Google Apps domain), but in practice we rarely had that many people join in the last UDS. This time around we’re going to encourage more people to join the video, especially community participants, so please check your webcams and microphones ahead of time to be ready. If you want to join, just ask one of the session leaders on IRC for the hangout URL. We are also investigating ways to embed the IRC conversations in the Hangout window, to make it easier for those on the video to keep track of the conversation happening there.

The Plenaries

Most people agreed that the mid-day plenaries didn’t work as well online as they do in person. There was also a desire to have a mid-day break to allow people to eat, stretch, or hold a sidebar conversation with somebody. So we are replacing the mid-day plenaries with a “lunch” slot, giving you an hour break to do whatever you need to do. We will be keeping the introductory plenary on the morning of the first day, because that helps set the tone, goals and information needed for the rest of the week. In addition to that, we have added back a closing plenary at the end of the last day, where track leads will be able to give a summary of the discussions and decisions made.

The Schedule

In addition to the above plenary changes, we have added an extra day to this UDS, making it 3 days instead of two. The last day will allow for overflow of sessions that couldn’t fit into 2 days, or the scheduling of follow-up session when it is determined they are necessary following a discussion earlier in the week.

Registration

Registration to attend will now be done in Summit itself, rather than through a Launchpad Sprint. So if you’re not a track lead, and you’re not registering Blueprints, there’s nothing you need to do on Launchpad itself. This will help those who do not have a Launchpad profile, though you will still need an Ubuntu SSO account to log in.

To register for UDS 13.04, go to the summit page, and just above the schedule you will see an orange “Register in Summit” button. If you don’t see that, you either need to log in to summit or you’ve already registered.

Summit Scheduler

Chris Johnston and Adnane Belmadiaf have been working hard to improve the Summit Scheduler website, taking feedback from attendees to improve the interface and workflow of the site. We will include as many enhancements as possible before the start of UDS 13.05. If you are interested in helping improve it, and you have some web development skills, please find them on #ubuntu-website on Freenode to find out how you can get involved.

Shortly after announcing the Ubuntu Phone, we made an ambitious and frankly unprecedented decision to make the development of the phone’s core apps a community initiative. We weren’t just open sourcing the apps being developed by Canonical (though we did that too), we would let the community drive the design and development of what would become the foundation of the Ubuntu Touch app ecosystem. And we would do it ten short months.

Work Item Tracking

Building 11 apps in less than a year is a lot of work, and tracking that work is itself a lot of work. To do this, we are using the same tools and process as the rest of Ubuntu’s development. This means using Launchpad for code hosting and bug tracking. But more importantly, it also means using Blueprints for planning, breaking the work into individual tasks, and assigning those tasks to individual contributors. This also allows us to use the Ubuntu Status Tracker to view the progress being made on those tasks. As of right now, that chart looks like this:

As you can see, when we started tracking them we had about 165 work items defined, and about 140 left to finish. As tasks are completed, and the developer updates the Blueprint with the new status of the work item, the orange part of the chart will shrink, and the green part will grow. If we can keep the green part on or below the black line, then we’re on track to finish them all by our October goal.

Milestones

Ten months is a short amount of time to build a collection of well designed and polished apps, but it’s also a very long time for planning development work. In order to narrow our focus and concentrate on immediate development tasks, we’ve further broken down the development period into a number of milestones, one for every month between now and October.

So instead of planning out the entire cycle, we will be scheduling tasks on a monthly basis. This will make the amount of work seem less daunting, and also give us a more agile cycle of planning, development, and evaluation. Each milestones will in turn get it’s own burn-down chart, so we can track the progress being made within the month as well.

Development Teams

Work items are also separated by team, which allows us to track the progress of individual projects, as well as the overall projects of the core apps campaign.

This allows teams to easily check if they are on track to complete their project by October, and also gives them an idea of how much (or how little) work remains to be done.

Next Steps

The first milestone, coreapps-13.10-month-0 is coming up in mid-April. For this milestone, we have been scheduling work items that were already making good progress, or that were small enough they could be completed in the two weeks between when it was defined and when it ends.

The milestone after that, ubuntu-13.10-month-1, ends mid-May, and will be our target for an alpha-level release of most of the apps. As you can see, there is still a lot of work to be done between now and then, but we are currently below the burn-down line, so as long as we keep the momentum going we will make that goal.

Everything not currently scheduled for one of these two milestones is targeted to the final October goal. Sometime in May we will begin scheduling work items for the coreapps-13.10-month-2 milestone, based on the progress made on these first two miles.