Canonical Voices

Posts tagged with 'quantal'

Daniel Holbach

Apps are super-important for Ubuntu. Many of us have blogged about this in a more general sense, but I want to provide an update of what has been happening behind the scenes in the last few weeks.

Before I start, I want to reach out to you to be part of the upcoming Apps Sprint. Join us on #ubuntu-arb on irc.freenode.net from Monday, 2nd July to Wednesday, 4th July to learn more about Ubuntu apps, get involved in reviewing them and bringing more progress to this effort.

Getting apps into Ubuntu hasn’t been easy up until now, due to a number of circumstances. The review process takes long, some of the steps involved are cumbersome and the review queue has been filling up. There are reasons for this and there is lots of room for improvement.

Technical requirements
As apps are part of a separate repository, the Technical Board requires us to make some very specific namespace distinctions between “regular packages” and apps. This means that apps install into /opt/ and files which can’t go there (.desktop files, lens specific bits, etc.) have to include the package name to avoid possible file name clashes.

This looks pretty straight-forward and you could just rename files and move things around as part of the packaging, but quite often this means you have to make changes in the code as well (think of file locations, translation files, data directories or file look-ups). For a larger app this results in quite a bit of engineering work to make all the changes and make sure they work as intended.

At this point I want to credit the App Review Board (ARB) for some work they have been doing. They could easily just have said: “Rejected: Your app doesn’t do it right.”, but instead they helped app authors to get their app working. This was time-consuming, but a learning experience for everyone involved.

The good news is: quickly, which is our recommended tool to produce apps, has templates where everybody worked hard to get the templates and the code up to scratch, so that writing code for the extras repository gets easier.

Another piece of good news is: pkgme has progressed nicely and can help with the initial packaging of apps (useful if you don’t use quickly).

I very recently started working on a tool called arb-lint, which automates certain parts of the app review. This will make it possible to collect the knowledge of app policies into it, so new ARB members or app review helpers can easily find out what’s wrong with an app and how to fix it. You could even run it on your own app and find out what needs to be improved.

To sum this up: everybody knows that packaging and policies is quite boring to app authors. They just want to focus on producing great quality apps, they’re not interested in tweaking their build-system to adhere to all the policies. Don’t worry – this is understood. There’s still work to be done, but the tools are all progressing nicely.

App submission
During the 18 months the App Review Board has existed, the submission process has changed a number of times. The tool which is now being used is called myApps and a lot of handy improvements have gone into it in the last weeks and months.

One current problem is that some app authors submit tarballs of their apps, others provide bzr branches, others submit their app in a PPA. While we know how to use all of these tools, it makes the review process fairly inconsistent. This is why we came up with a service called apps-brancher, which downloads the app’s code, sticks it into a bzr branch, attempts to package it if necessary and pushes it to Launchpad.

Staffing
The current ARB members are all volunteers and working hard on apps and other places in Ubuntu. Some weeks ago the Ubuntu App Review Contributors team was set up, so that more active helpers can easily join the effort.

Summary
It is true. There is quite a backlog of apps. Some of them might be reviewed and approved quickly, others will need quite a bit of engineering to get into Ubuntu. Some might not be suitable for the extras repository at all.

As you have read above, there are numerous improvements in the works and there are very likely lots of other things which might result in a nice speed-up. Your help will be appreciated here!

The Ubuntu Apps Sprint
All of the above is why we want to invite you to the Ubuntu Apps Sprint from Monday to Wednesday (2nd-4th July). Join us in #ubuntu-arb on irc.freenode.net to:

Quite a number of experts from the ARB, from the quickly and pkgme teams and lots of others will be around to answer your questions. We hope you will get involved and help us out.

Apps will make Ubuntu even more beautiful. It’s just great to get to see so much creativity first. Contributing here is totally worthwhile.

Read more
Daniel Holbach

Some of you might remember when Andrew Starr-Bochicchio send out the Developer Advisory Team’s analysis of the feedback new contributors gave us. It was a great read, told us a lot about how new contributors get involved, but it was a also quite a bit of work.

As we conducted most of our interviews via mail, we had lots of answers in our inbox. As a team, we put them into a Google Doc and after the release cycle had passed, we had amassed 6 months worth of feedback. Sometimes just a few lines which concentrated on just one topic, but sometimes heaps of text covering each and every point of their developer experience.

As we feel this was quite a bit of work, but also worth doing, we want to continue this effort. Still we are looking for ways to improve this. If you have ever done anything along these lines, we’d love to learn from your experience. How can we optimise this process?

A few requirements we have:

  • No surveys. When we reach out to new contributors we are interested in a conversation with them and not necessarily interested in getting them to rate and judge each and every bit they might have interacted with. By reaching out to them, we already ask them to spare us some of their time, a long survey would likely give us more structured feedback, but less responses.
  • No expensive text analysis software.

If you have any ideas how we can optimise the process, please let us know.

Also if you are interested in helping out the Developer Advisory Team, please get in touch.

 

Read more
Daniel Holbach

… for planning things, but also for getting things done.

In-between sessions I had discussions with many many folks and I’m happy to say there was renewed and much interest in the Packaging Guide.

Heroes like Andrew Starr-Bochicchio, Leo Iannacone, Joseph Mills and others have contributed suggestions, code, ideas and text bits to improve the packaging guide, and that’s on top of what was discussed in the session we had.

During the session we identified a number of areas of focus. In no particular order, there’s:

  • Include the Packaging Guide in Ubuntu
  • Translate it in as many languages as possible
  • Merge the Wiki documentation into the guide
  • Do user-testing of the guide
  • Do an editorial review of all the content

Also in many other sessions, the Packaging Guide was usually deemed the best place to educate new contributors about how things work, which is great.

What happened this week (outside of sessions) already was:

This level of activity is fascinating and bodes well for a great 12.10 cycle.

What I love most about the guide is that everybody can help us if you have just a little bit of interest in Ubuntu Development. Let’s have a quick look at some bugs you could help out with, if you’re interested.

Here’s some ‘bitesize’ bugs, I hope we can you interest in:

Obviously, there’s more bugs and there’s a blueprint to subscribe to. Feel free to grab a bug and help out, or catch us on IRC and find out how you can get involved.

Update: I forgot to mention John Kim, who has contributed a bunch of bug reports with his experience. Great work, John!

Read more
Daniel Holbach

Jono blogged about the importance of application developers to Ubuntu earlier and I wanted to echo some thoughts and add some of my own.

I have been in the Ubuntu Developer camp for most of Ubuntu’s life as a project, so the mindset of “App developers? Why don’t they just set up an open source project and get it packaged?” or “Apps? We have packages.” is what I have heard a couple of times already and is what I would probably have answered some years ago myself.

The power of the Open Source community and having open projects is immense. We all have seen it many times: a thought, a great idea, some dedicated contributors, good communication and a friendly community can achieve amazing things. This happens every single day.

We are well aware of how things work in the Open Source world and we have recently seen the success of our great work: millions of users, who have never dabbled in Open Source before, today enjoy Ubuntu (or other pieces of Free Software) and rely on it. We have managed to reach out to an entirely new demographic and continue to grow our user base.

With new demographics there are new expectations and new responsibilities. Consider my father for example. He follows what’s going on in the Ubuntu world, but will occasionally point out to me that an app he’s interested in buying does not exist for Ubuntu. The last I remember him talking about was a good language learning course.

With new form factors and devices running Ubuntu (you know, TVs, tablets, phones, watches, cars, coffee machines, hoverboards and the like), there are going to be thousands of useful helper tools out there which might not be available for Ubuntu yet. Add to that the growing number of content providers (magazines, books, maps, music, etc.) which users yet can’t easily get “for Ubuntu”.

This is the world we are looking at today and it becomes obvious that apps should be a first-class citizen in Ubuntu. Don’t get me wrong. I’m all for making everyone who shows the slightest interest in working on Ubuntu itself an Ubuntu developer and member of our community, also because I feel that everyone who is part of this has a lot to gain, personally and for their particular project. It just shouldn’t be a strict requirement because it won’t scale.

A number of teams have been working very hard on making seamless apps in Ubuntu a reality and that’s just great to see. It’s a hard problem to solve because it involves so many different important pieces. Keep up the good work everyone!

At UDS I’m definitely going to (among other sessions, I’ll blog about later on) attend these sessions to see what we can do about making apps in Ubuntu more exciting and something that just works:

Hope to see you there!

Read more