Canonical Voices

Posts tagged with 'launchpad'

pitti

You can now start translating Ubuntu Saucy on Launchpad.

Read more
bigjools

A few years ago I wrote a contrib script for Launchpad’s launchpadlib called ‘close-my-bugs.py’ which attempted to close (aka mark them ‘fix released’) all of your bugs in a project that were targeted to a particular milestone.

For various reasons it grew out of date and when I needed to use it recently, it didn’t work!  Long story short, I just fixed it up and added a couple of new features:

  • You can optionally close just your own bugs, or all the bugs in the milestone
  • You can search for bugtasks targeted against a series in your project (these are not normally picked up when searching in a project’s milestone)

You can grab the code here:

bzr branch lp:launchpadlib

contrib/close-my-bugs.py

Read more
bigjools

Error handling in Go

There’s been a debate raging in some corners of the internet lately about how superior Go‘s error handling is to other languages.  I am going to address some of the points made, here:

Claim 1: It’s impossible to ignore errors in Go, they are “in your face”

This is patently false.  Take this example:

fmt.Println("Hello world")

Pretty innocuous wouldn’t you say?  Well let’s take a look at the language documentation for fmt.Println:

// Println formats using the default formats for its operands and writes to standard output.
// Spaces are always added between operands and a newline is appended.
// It returns the number of bytes written and any write error encountered.
func Println(a ...interface{}) (n int, err error)

So Println can return an error!  Where did we check it?  Well, we didn’t.  Any other claims that it’s OK to ignore it in this case further strengthen my argument.

Some will say that it’s a deliberate choice to ignore the error and I deserve all I get. Well, was it? I didn’t even know that Println returned an error until I looked at the documentation (and who is going to do that for Println?). And that’s the point, if I need to look at the documentation to see that it can return an error, then if I am using a language that raises exceptions I will have also seen its documentation about how it deals with errors.

You could even argue that an exception is superior in this case.  With Go, the code will march on regardless, oblivious to the fact that Println failed.  With exceptions, it’ll fail and show you exactly where it failed.

The language will error at compile time if you try to ignore an error returned as a second value and you only take the first.  But this is trivially bypassed by assigning it to _, which when reading code is easily missed compared to the exception style of “catching then dropping”, because Go itself encourages this style of assigning to _ with its own range statement as a deliberate way of ignoring things that the language is trying to force you to see.

So really in both cases, ignoring the error doesn’t really stand out as wrong.

Here’s a concrete example in Go I was recently shown:

w := bufio.NewWriter(os.Stdout)
for _, name := range ListAll(conf) {
    fmt.Fprintln(w, name)
}
w.Flush()
return

As you can see, the caller completely forgot to check the error returned from Fprintln and Flush and there would be no compiler warning about it.

Claim 2: Exceptions teach developers to not care about errors

Citing an example where someone didn’t catch an exception and the code consequently blew up is really not a good example of this claim.  It’s a bug, for sure and you get a full traceback of your error in the resulting exception, which is handy.  You go away and fix it quickly based on that info.

If I am in the same situation with Go and I ignore a returned error from a function, at some point (which is likely to be nowhere near the place where the error occurred) my code will blow up.  I’ll have to run up the debugger to try and find out where it really occurred though.

Because unused variables in Go are a compile-time error, it’s actively discouraging you from assigning the result of the function to a variable (or you can deal with it, of course).  For anyone who’s not read the full documentation for a function call or missed its return value (we’re all human) as I said above – you’re not even going to notice that you missed it.

Based on this, I can see no difference at all that suggests one way or the other teaches developers to not care about errors.  Developers do care about errors, really, but bugs creep in however careful you are.  And when they do, I’d rather have a decent indication of where the bug is.

Other parts of error handling that I dislike

When you look at the average Go program, you will see a lot of this:

if err != nil {
  return nil, err

This is the recommended way of error handling in in Go.  But this is not error handling, it’s error propagation.  In nearly all languages there will arise situations where in well-factored code you have a low-level error that you need to pass right back up to the entry point for the caller. That means you need this error propagation code in every single place where you check for errors.  There’s no syntactic sugar, just the same three lines everywhere.

For me, this vastly decreases the readability of the code. This is where exceptions excel because inside my own library I can factor the bejeesus out of it into many small functions and if I need to return an error, I just catch a lower-level exception in the top-level function and return something else.  You can do this in Go with a panic(), but it seems to be discouraged.  Panic() feels almost exactly like using exceptions, only the syntax is worse. If Go’s style is to encourage people to handle errors like this, it needs the sugar.

Conclusion

Many people might think that I completely hate Go’s error handling from this post.  That’s not strictly true – I don’t hate it, I just think it can be improved.  I challenge assumptions that I see which state that Go’s error handling is superior in some way, when as far as I can see it’s not that different from other languages in terms of usefulness.

Go is clearly in its infancy.  Most languages will have started out with youthful enthusiasm and realised that some change was needed.  These languages are the successful ones where developers enjoy coding in it and feel productive.  I hope that Go embraces change as it matures and attracts more developers.

I welcome comments on this post – unlike some people I won’t censor them or delete ones I can’t argue with (unless they are outright abusive and use foul language, this is a family blog!).


Read more
David Planella

I am pleased to announce that our current development release, Ubuntu Precise, is now open for translation:

Translate Ubuntu!

Translate Ubuntu Oneiric!

Some additional information that will be useful for translators:

  • Translation schedule. Remember that according to the release schedule translatable messages might be subject to change until the User Interface Freeze on the week of the 23rd of February.
  • Language packs. During the development cycle, language packs containing translations will be released twice per week except for the freeze periods. This will allow users and translators to quickly see and test the results of translations.
  • Test and report bugs. If you notice any issues (e.g. untranslated strings or applications), do check with the translation team for your language first. If you think it is a genuine bug, please report it.
  • Learn more. Learn how to start translating Ubuntu and enable millions to use it in their language.

Ubuntu 12.04 will be a Long Term Support release, so let’s rally around translations to provide the best translated OS around and go over the mark of nearly 40 languages in which Ubuntu is fully translated!

open image by loop_oh – License: CC by-nd 2.0

Read more
Laura czajkowski

Launchpad has been a key tool used in developing Novacut. I use Launchpad for code hosting, bug tracking, daily builds, and more. For almost two years I’ve been doing monthly stable releases on Launchpad, and Novacut now spans six separate Launchpad projects. To say the least, I’ve learned a lot about Launchpad in the process.

I don’t think Novacut could be where it is today without Launchpad, so I want to pass on some of what I’ve learned the past two years. Here are my five essential Launchpad best practices:

1. Daily Builds

I’m always very thankful that early on Paul Hummer took the time to school me on using Source Package Recipes to do daily builds. This Launchpad service gives you automated package builds across multiple architectures, and multiple Ubuntu releases.

I don’t know how to emphasize this enough, but seriously, you need daily builds. As a point of reference, daily builds are the 3rd item in the famed Joel Test.

These builds are triggered simply by making commits to the appropriate bzr branch on Launchpad (usually your trunk branch). You’ll automatically get up to one build per 24-hour period, and you can manually trigger additional builds when needed.

You can include your debian/ packaging directory in your project source tree, or you can keep debian/ in a separate bzr branch. For the Novacut components, I’ve found it most helpful to keep debian/ in the source trees because it’s handy to be able to land a code change and its corresponding packaging change in a single merge. This works for us because we currently can use the exact same debian/ for all the Ubuntu versions we support. If that’s not true for your project, you’ll need multiple debian/ branches.

For reference, here’s the Novacut Source Package Recipe.

2. Unit Tests

You should run your unit tests during your package builds, and you should fail the build when any unit test fails. This is particularly important for daily builds, because this will prevent a package with broken unit tests from reaching your daily PPA.

The Launchpad build servers are strict and unforgiving environments, which is a good thing when it comes to unit tests. The build servers are also probably quite different from your local development environment. On countless occasions our daily builds have caught failures that only occur on i386 (my workstation is amd64), or only occur on an Ubuntu release other than the one I’m running, etc.

To run your unit tests during the package build, you’ll need to modify your debian/rules file as appropriate. If you’re using debhelper, add an override_dh_auto_test target.

You might also need to add additional packages to the Build-Depends section of your debian/control file, packages that are needed by the unit tests but are otherwise not needed by the build itself.

For reference, here’s the debian/rules file used to run the Dmedia unit tests (which is also a handy Python3 example).

3. Track Ubuntu+1

When a new Ubuntu version opens up for development, I immediately start doing daily builds on the development version, even though I don’t typically upgrade my own computers till around 4 months into the cycle.

I use daily builds on the development release as an early warning system. With no extra effort on my part, these builds give me a heads-up about code or packaging changes that might be needed to make Novacut work well on the next Ubuntu release.

To enable daily builds on the next Ubuntu version, just go to your Source Package Recipe, click on “Distribution series”, and check the box for the newest series. Now you’ll have daily builds on the newest Ubuntu version, in addition to all the versions you were already building for.

For example, I’m currently in the process of enabling daily builds for Raring, as you can see in the Microfiber Source Package Recipe. And I did indeed encounter a build failure on Raring, seemingly caused by a debhelper issue.

For the first month or so in a cycle, I don’t tend to worry much about build failures on the development version. But after the dust has settled a bit, I make sure to keep the builds in working order, and I even do monthly stable releases for the Ubuntu development version. Again, I do all this pro-actively even before I personally start running the newest Ubuntu version.

4. PPAs & Users

Whenever someone asks me why I use Launchpad instead of github, my short answer is always, “PPAs and users”.

Source Package Recipes give you much more than just a build, they give you daily packages that are easily consumable by your testing community and early adopters. This tight feedback loop prevents you from running too far ahead without getting a good reality check from your target users.

Keep in mind that for some products, the early adopters willing to install from a PPA might not be all that representative of your target user. So when it comes to making design decisions, you might need to politely ignore certain feedback from some of these early adopters. In my experience, this wont cause any hard feelings as long as you have clearly communicated who your target user is, and why.

For reference, you might look at the way we’ve defined the Novacut target user.

I recommend creating PPA names that are well-branded and easy to remember. First, create a Launchpad team with the same name as your product. In our case, we have a ~novacut team. Second, I recommend creating a daily and a stable PPA owned by the same team. In our case, that gives us two easy to remember PPAs:

Although none of our target users (professional video editors) currently use Ubuntu to do their job, I’ve been surprised by how many follow Novacut’s development via our stable PPA, and even our daily PPA. This has helped keep us on track, and has helped us build customer loyalty even before we have a finished product.

For me personally, this daily user engagement also makes the design and development process more enjoyable. It’s hard to empathize with an abstract persona; it’s easier to solve specific problems for specific people.

5. Use Apport

Till recently I didn’t realize that you can use Apport for automated crash reporting in unofficial packages delivered through a PPA.

We haven’t had Apport integration for that long, but it’s already provided us with dozens of highly valuable crash reports. Almost immediately some hardware specific issues came to light and were fixed, convincing me that a key benefit of Apport is knowing how your app might misbehave on a larger, more variable pool of hardware.

Apport also helped some rare bugs come to light. I thought Dmedia was basically crash-free, but those one-in-a-thousand bugs pop out quickly when thousands of people are running it. Most of these bugs would have eventually been found by one of our core devs, but the quicker a bug is discovered, the quicker and easier the bug is to fix.

For more info, check out this blog post and this screencast, where I covered our Apport integration in detail.

And for reference, see the merge proposal that added Apport integration in Novacut.

A big thank you to Jason DeRose for sharing how his project uses Launchpad on a daily basis.

 

Read more
Curtis Hovey

I have been analysing Launchpad’s critical bugs to track the Purple squad’s progress while on Launchpad maintenance duty. In January of 2011, the Cloud Engineering team né Launchpad Engineering team was reorganised into squads, where one or more squads would maintain Launchpad while other squads work on features. This change also aligned with a new found effort to enforce the zero-oops policy. The two maintenance squads had more than 332 critical bugs to close before we could consider adding features that the stakeholders and community wanted. By July 2011, the count dropped to its lowest point, 250 known critical bugs. Why did the count stop falling for fifteen months? Why is the count falling again?

Charting and analysing critical bugs

Chart of Launchpad's critical bugs since the formation of Launchpad squads and maintenance duties
The chart above needs some explanation to understand what is happening in Launchpad’s critical bugs over time. (You may want to open the image in a separate window to see everything in detail.) Each iteration is one week. The backlog represent the open critical bugs in launchpad at the start of the iteration. The future bugs are either bugs that are not discovered, not introduced, or reported and fixed within the iteration. The last group is crucial to understand the lines plotting the number of bugs fixed and added during the iteration. We strive to close critical bugs immediately. Most critical bugs are reported and fixed in a few days, so most bugs were not open long enough to be show up in the backlog. The number of bugs fixed must exceed the number added to make the backlog count fall. You can see that the maintenance squads have always been burning down the critical bugs, but if you are just watching the number of open bugs in Launchpad, you get the sense that the squads are running to just stand still.

I use the lp-milestone YUI widget to chart the bugs and analyse the our progress through the critical bugs. It allows me to summarise a set of bugs, or analyse a subset by bug tag.

Launchpad maintenance analysis -- driving critical bugs to zero

Though 22 bugs were fixed this past week, 14 were added, thus the critical count dropped by 8. The last eight iterations are used to calculate the average bugs closed and open per iteration. The relative velocity (velocity – flux) is used to estimate the remaining number of days to drive the count to zero. When the Purple squad started maintenance on September 10th of 2012, the estimated days of effort was more than 1,200. In just three weeks, the number has fallen dramatically. The principle reason the backlog of critical bugs has fallen is that the Purple squad is now giving those bugs their full attention, but that generalisation is unsatisfactory.

Why is the Purple squad so good at closing bugs in the critical backlog?

I do not know the answer to my question. The critical backlog reached its all-time low of 250 bugs with the release of the Purple squad’s maintenance work in July 2011. There was supposition that  Purple fixed the easy bugs, or that the fixes did not address the root cause, so another critical bug was opened. I disagree. The squad had no trouble finding easy bugs, and it too would have been fixing secondary bugs if the first fix was incomplete. I can tell you how the squad works on critical bugs, but not why it is successful.

I was surprised to see the Purple squad were still the top critical bug closers when it returned to maintenance after 15 months of feature work. How could that be?  The squad fixed a lot of old timeout and JavaScript bugs in the last few months through systemic changes — enough to significantly affect the statistics. About 600 critical bugs were closed while Purple squad were on feature work. The squad closed 210 of those bugs. 60 were regressions that were fixed within the iteration, so they never showed up in the backlog. 70 critical bugs were fixed because they blocked the feature, and 80 critical bugs were because Purple was the only squad awake when the issue was reported. The 4 other squads fixed an average of 98 bugs each when they were on maintenance. The Purple squad fixed more bugs then maintenance squads on average even when they were not officially doing maintenance work.  The data, charts, and analysis always includes the Purple squad.

I suspect the Purple squad has more familiarity with bugs in the critical backlog. They never stopped reading the critical bugs when they were on feature work. They saw opportunities to fix critical bugs while solving feature problems. I know some of the squad members are subscribed to all critical bugs and re-read them often. They triage and re-triage Launchpad bugs. This familiarity means that many bugs are ready to code — they know where the problem is and how to fix it before the work is assigned to them. They fixed many bugs in less than a day, often doing exactly what was suggested in the bug comments.

During the first week of their return to maintenance, about 30 critical bugs were discovered to be dupes of other bugs. Though this change does make the backlog count fall, it also revised all the data, so the chart is not showing these 30 bugs as at all now. The decline of backlog bugs does not include dupes. While the squad was familiar enough to find many bugs that they close in a single day, they were not so familiar as to have known that there were 30 duplicate bugs in the backlog when they started.

Most squad have only one person with DB access, but the Purple squad is blessed with 3 people who can test queries against production-level data. This could be a significant factor. It is nigh impossible to fix a timeout bug without proper database testing. Only 13 of the recent bugs closed were timeouts though. The access also helps plan proper fixes for other bugs as well, so maybe 20% of the fixed bugs can be attributed to database access.

Maybe the Purple squad are better maintenance engineers than other squads who work on maintenance. For 28 months, I was the leading bug closer working on Launchpad. I closed 3 times more bugs than the average Launchpad engineer. I am not a great engineer though. My “winning” streak came to a closed shortly after William Grant started working on Launchpad full time; he soundly trounced me over several months. Then he and I were put on the same squad and asked to fix critical bugs. Purple also had Jon Sackett, who was closing almost 2 times the number bugs than the other engineers. I don’t think I need to be humble on this matter. To use the vulgar, we rocked! Ian was the odd man on the Purple squad. He was the slowest bug closer, often going beyond our intended scope to fix an issue. Then Purple switched to feature work…Ian lept to the first rank while the rest of the squad struggled. Ian fixed almost double the number of Disclosure bugs than other squad members. The leading critical bug closer on the squad at the moment though is Steve Kowalik. This is his first time working on maintenance. His productivity has jumped since transitioning to maintenance.

I can only speculate as to why some engineers are better at maintenance, or can just close more bugs than others. A maintenance engineer must be familiar with the code and the rules that guide it. Feature engineers need to analyse issues and create new rules to guide code. I did not gradually become a leading bug closer, it happen in a single day when I realised while solving one issue that the code I was looking at was flawed, it certainly was causing a bug, I knew how to fix it, and with a few extra hours of extra effort, I could close two bugs in a single day. Closing bugs has always been easy since that moment.

I believe the Purple squad values certainty over severity and small scope over large scope when choosing which critical backlog bugs to fix. I created several charts that break the critical bugs into smaller categories. I suggested the squad burn down sub-categories of bugs like regressions, or 404s. The squad members are instead fixing bugs from the entire backlog. They are choosing bugs that they are certain they can fix in a few hours.  I think the squad has tacitly agreed to fix bugs that are less than a day of effort. When this group is exhausted, they will fix issues that require days of effort, but also fix as many bugs. The last bugs to be fixed will be those that require many days to fix a single bug. Fixing the bugs with the highest certainty reduced our churn through the critical bugs, there are fewer to triage, to dupe, to get ready to code.

The Purple squad avoids doing feature-level design and effort to fix critical bugs. Feature-level efforts entail more risk, more planning, and much more time. There is often no guarantee, low certainty, that a feature will fix the issue. A faster change with higher certainty can fix the issue, but leaves cruft in the code that the engineers do not like. Choosing to do feature-level fixes when a more certain fix is available indicates there is tension between the Launchpad users who have a “critical” issue that stops them from using Launchpad, and the engineers who have a “high” issue maintaining mediocre code. I contend it is easier to do feature-level work when you are not interrupted with maintenance issues. When the Purple squad does choose to do feature-level work to fix a critical, they have a list of the bugs they expect to fix, and they cut scope when fixing a single bug delays the fix of the others. The Launchpad Answers email subsystem was re-written when other options were not viable, there we about 20 leading timeouts represented by 5 specific bugs to justify 10 days of effort to fix them.

The Purple squad is not unique

Nothing that I have written explains why the Purple squad are better are closing critical bugs. All squads have roughly the same skills and make decisions like Purple. Maybe the issue is just a matter of degree. If the maintenance squad is not closing enough bugs to burn down the backlog, their time is consumed by triaging and duping new critical bug reports. Familiarity with Launchpad’s 1000′s of bugs is an advantage when triaging bugs and getting a bug ready to code. Being able to test queries yourself on a production-level database takes hours or days off the time needed to fix an issue. Familiarity with the code and the reasoning that guided it increases the certainty of success. The only domain that Purple is not comfortable working with is lp.translations; the squad is comfortable changing 90% of Launchpad’s code. There may be correlation between familiarity with code, and the facts that the squad members participated in the apocalypse that  re-organised the code base, and that some have a LoC credit count in the 1000′s.

Read more
Laura czajkowski

We’re offering a unique opportunity to take part in one of the most exciting changes to affect the technology industry: the move to the cloud.

As Technical Writer in Canonical’s Launchpad team you’ll find the best way to ensure that users and developers of our software understand its benefits and how to use it. Whether it’s traditional documentation, screen casts or blog posts, you’ll find it easy to choose the right medium and you’ll have all the skills necessary to produce compelling, involving and effective content.

You’ll thrive in a rapidly changing environment where you’ll be expected to grasp new concepts quickly, develop an intimate understanding of three or four products simultaneously and determine the day to day shape of your own work.

A skilled writer, you’ll excel at finding the right information from your research and then communicating it with a casual confidence that puts people at ease and, most importantly, leaves them with the understanding they need to be effective.

Reporting to the team’s Product Manager, you’ll work as part of a fun-loving, highly skilled, global development team who produce tools including Launchpad, MAAS and Bazaar. You’ll share our love of hard work and our passion for free software, Ubuntu and the cloud.

  Key responsibilities and accountabilities

  •  Explain our products through traditional documentation, screencasts, podcasts and any other appropriate method.
  • Help ensure community and developer engagement with our platforms by documenting APIs and communicating the benefits of our various offerings.
  • Tell the story of the products we develop, through compelling blog posts and white papers.
  • Speak directly to the communities who use and develop our software in order to plan how you can best cater to their needs.

  Required skills and experience

  •  Your written English is well crafted, compelling and fun. You care about how you write, as much as what you write. You’ve produced end-user documentation, developer documentation, blog posts and white papers. What’s more, you enjoy doing it.
  • You have at least five years’ experience as technical writer, whether that’s professionally or as a consistent contributor to open source projects.
  • You’re smart: you find no problem in learning and owning a new concept.
  • When you speak, you find an instant rapport with your conversational partner or audience, and have no trouble in pitching your message appropriately.
  • When you listen, you ask all the right questions and can use the answers to create content that is appropriate to your audience and the information you need to communicate.
  • You live and breathe open source technology. You know the industry, understand the community and share the ideals. You know your OpenStack from your Intel, your ARM from your aaS and your Bugzilla from your Git.
  • You’re equally comfortable dealing with people in person, by phone, over email or using IRC and other remote communication tools.
  • You are willing to travel internationally, for periods of one or two weeks and occasionally longer, for conferences, developer-oriented meetings and sprints.

Desirable skills and experience

  •  You’ve worked as part of team building cloud-related technologies or developer tools.
  • You use Ubuntu and are familiar with Launchpad and Bazaar.
  • You have a familiarity with one or more of the following:
    • IaaS platforms such as OpenStack, AWS, Eucalyptus
    • Ubuntu Server, particularly in cloud contexts
    • ARM server
    • distributed version control systems
    • a form of Linux packaging, such as .deb or .rpm
    • Python development
  • You have taken an active role in an open source software project and understand the dynamics, demands and constraints of working in a distributed community of volunteer and paid developers.
  • You’ve worked as part of a distributed team and can demonstrate the self-motivation and discipline required in such an environment.

Apply online, if you have any questions drop by #launchpad

Read more
James Henstridge

One of the projects I’ve been working on has been to improve aspects of the Ubuntu One Developer Documentation web site.  While there are still some layout problems we are working on, it is now in a state where it is a lot easier for us to update.

I have been working on updating our authentication/authorisation documentation and revising some of the file storage documentation (the API used by the mobile Ubuntu One clients).  To help verify that the documentation was useful, I wrote a small program to exercise those APIs.  The result is u1ftp: a program that exposes a user’s files via an FTP daemon running on localhost.  In conjunction with the OS file manager or a dedicated FTP client, this can be used to conveniently access your files on a system without the full Ubuntu One client installed.

You can download the program from:

https://launchpad.net/u1ftp/trunk/0.1/+download/u1ftp-0.1.zip

To make it easy to run on as many systems as possible, I packaged it up as a runnable zip file so can be run directly by the Python interpreter.  As well as a Python interpreter, you will need the following installed to run it:

  • On Linux systems, either the gnomekeyring extension (if you are using a GNOME derived desktop), or PyKDE4 (if you have a KDE derived desktop).
  • On Windows, you will need pywin32.
  • On MacOS X, you shouldn’t need any additional modules.

These could not be included in the zip file because they are extension modules rather than pure Python.

Once you’ve downloaded the program, you can run it with the following command:

python u1ftp-0.1.zip

This will start the FTP server listening at ftp://localhost:2121/.  Pointing a file manager at that URL should prompt you to log in, where you can use your standard Ubuntu One credentials and start browsing your files.  It will verify the credentials against the Ubuntu SSO service and issue an OAuth token that it stores in the keyring.  The OAuth token is then used to authenticate requests to the file storage REST API.

While I expect this program to be useful on its own, it was also intended to act as an example of how the Ubuntu One API can be used.  One way to browse the source is to simply unzip the package and poke around.  Alternatively, you can check out the source directly from Launchpad:

bzr branch lp:u1ftp

If you come up with an interesting extension to u1ftp, feel free to upload your changes as a branch on Launchpad.

Read more
Laura czajkowski

Vincent

Laura:  What do you do on the Launchpad team?
Vincent: Maintenance. Although I’m eagerly waiting for the sprint with gmb to get some hints on how to handle the beast :)  In the mean time, I’m focusing on fixing bugs and making the udd importer more testable.

Laura: Can we see something that you’ve worked on?
Vincent:  https://launchpad.net/bzr  and http://babune.ladeuil.net:24842/

Laura: Where do you work?
Vincent:  At home

Laura: What can you see from your office window? View from where I sit
Vincent: The venerable Strasbourg post office, lovely old stones.

Laura:  What did you do before working on the Launchpad team?
Vincent:  Developing bzr.

Laura:  What did you do before working at Canonical?
Vincent:Various service/consulting work for > 20 years, including some episodes at software editors.

Laura: How did you get into free software?
Vincent:  With pleasure

I think the most important event was in 1993: I encountered a blocking bug in g++ related to C++ templates (way before it was standardized). That was a roadblock, no work-around and it was Friday afternoon. In despair, I posted a reproducing case in the related newsgroup. When I came back to work on Monday I got an email telling me the bug was known *and* fixed *and* where to get the patch for the compiler.

That was a light-bulb instant: free software support could be far superior to commercial software support !

One week later, I got a second email asking me if I was out of trouble… Amazing, not only did I get a fix faster than I could have dreamed, but the guy *came back* to ensure I got it…

I never looked back.

Laura:  What’s more important? Principle or pragmatism?
Vincent:  Both are important. If you forget one, be prepared to pay the cost. Both are dangerous too if you forget the other:

- being pragmatic only most often means you’re adding to your tech debt or rely on others to finish your work,

- respecting principles excessively means you never deliver anything.

Laura: Do you/have you contribute(d) to any free software projects?
Vincent: bzr is my most important contributions (including a few plugins). I’ve occasionally sent patches to gtk, perl modules and various other bzr upstream projects.

Laura:  Tell us something really cool about Launchpad that not enough people know about.
Vincent:  Pass  :)

Laura:  Is there anything in particular that you want to change in Launchpad?
Vincent:  Make it easier to test against for all projects that rely on it (I’m probably biased here as the udd importer severely suffer from not being able to properly test interactions with launchpad (read *and* write (branch creation mainly)).

Read more
Laura czajkowski

Jelmer Vernooij

Laura: What do you do on the Launchpad team?
Jelmer: I’m one of the blue haired freaks on the Launchpad blue squad, although my hair isn’t actually blue – I’m sure we can fix this at the next squad sprint. At the moment, we are working on maintenance: fixing
critical bugs in Launchpad and dealing with incidents.

Laura: Can we see something that you’ve worked on?
Jelmer: I’ve contributed quite a bit to the code behind recipe builds. Most of my work has been on the backend though, not directly user-visible.

Laura: Where do you work?
Jelmer: Like most of us I work at home, which in my case is in Utrecht, the Netherlands. Occasionally I cowork with other teleworkers in Utrecht.

Laura: What can you see from your office window?
Jelmer: At the moment, I see just a big sad drapery made out of rain. On brighter days, I look out on a park and a canal.

Laura: What did you do before working on the Launchpad team?
Jelmer: The Blue squad, which I’m currently in, was originally the Bazaar team. Before that, I worked on the Launchpad team too. This was back in the days when there were no squads, but teams – I was in the Soyuz team. The inimitable Matt Revell interviewed me back in 2010:

Laura: How did you get into free software?
Jelmer: A long time ago, in high school, I ended up maintaining a few server machines running FreeBSD and Samba. After hitting some bugs, a dive into the source code followed to see what I could fix. I’ve been involved with various free software projects ever since.

Laura: What’s more important? Principle or pragmatism?
Jelmer: Do I really have to choose? That’s not very pragmatic.

Laura: Do you/have you contribute(d) to any free software projects?
Jelmer: Beside Launchpad, the main free software project I am involved in is Samba. There are several other projects that I have made major contributions to, such as Bazaar, CUPS, Wireshark, OpenChange, BitlBee.

I’m a Debian maintainer and Ubuntu uploader, mostly for projects I am involved in upstream. This knowledge comes in handy when working on the archive side of Launchpad.

Laura: Tell us something really cool about Launchpad that not enough people know about.
Jelmer: https://launchpad.net/builders lists all the Launchpad builders and
the mischief they are up to.

Laura: Is there anything in particular that you want to change in Launchpad?
Jelmer: It would still be really nice to have dashboards of some kind in
Launchpad. There is even a LEP.

Read more
mitechie

Phew, well one day down. I dove head first into Canonical and Launchpad today. It’s a bit amazing the amount of information and parts there are to everything. Everyone welcoming me throughout the day was great, but my head is still spinning a bit for sure.

I managed to get a nice starter walk-through of Launchpad and find my way through a superficial bugfix and merge request. So hey, that wasn’t so bad heh. It’s kind of exciting to throw out all my usual tools I’ve been mastering for a while and start over. Make files, zpt files, ZCA, and YUI run the show. Time to see how people get things done without Fabric, Mako, and SqlAlchemy.

I’m really excited to get to some real change and hope to pick things up quickly. I know a while ago I was disappointed that Launchpad wasn’t taking advantage of some of the Javascript driven UI enhancements that we can do these days. The change of that is already in full swing and my team is looking to land a nice chunk on the bugs UI shortly. Let’s get to work!


Read more
bigjools

As most of my colleagues know, I am a KDE fan.  I love using Kubuntu, despite its lack of “official” attention from Canonical.

I’ve heard all this fuss about Unity and I’ve no real idea what it’s all about, so I thought I’d give it a try.  Today will be my first full day of using it (and the last for 2 weeks since I am heading out on vacation) and I will attempt to write up my experiences.  It’s a bit of a brain dump, but here follows day one!

First impressions

My initial impression is that it looks pretty slick, but not as pretty as KDE4.  I’m clicking around a bit to see what’s what and I’ve immediately noticed a few things that I will miss from KDE:

  • There doesn’t seem to be a way to put widgets on the panel – I want my CPU/MEM/SWAP meter! (Some time later I found “indicators” in the Software Centre, there’s a system load indicator, but after installing there’s no obvious way of using it)
  • I am used to ctrl-F<N> to switch virtual desktops, I can’t see a way of emulating that.  (Ok I found the setting an hour later, great)
I’m also not sure about the global menu thing, I’m finding it a lot more effort to mouse around to get to menus.
Right, so let’s try and configure things as I like them.  First, I am a focus-follows-mouse junkie (I first used X Windows in the early 1990s with twm!) so let’s poke around in the settings.  Hmmm, doesn’t seem like I can change that… Ok some quick Googling reveals I have to install a so-called compiz settings manager and run ccsm. Right, I can set it in there.  That’s bizarre that I have to install something to edit more settings!
Now, focus-follows-mouse  has also made the global menu even less desirable as it changes to whatever app I mouse through to get to it. Eugh.  (I realise this is a concious design decision by the Unity team, rather than a shortcoming though – doesn’t mean I have to like it!)

Visual differences

Ok so I’ve had some more time to get used to the layout now.  More thoughts:
  • The icons on the left have some weird triangles on them, some solid some not.  I’ve no idea what they mean, but I am sure I will find out at some point.
  • It seems like I have to run an application before I can add it to the left panel as a quick launcher (by setting “Keep in Launcher”)
  • The KDE file browser Dolphin is massively better than Nautilus (I’ll write more about that some other time)
  • The mail indicator is a nice idea at the top right, but it wants to use Evolution.  I don’t! How can I make it use kmail?
  • Having a music player integrated into the volume indicator is a nice touch. I’d like to use Amarok though; it lists it but there’s no controls for it.
  • Clicking on the time indicator shows a calendar, like KDE.  I suspect I can’t use an arbitrary calendar app though, it seems tied to evolution.
  • The logout button shows a load of seemingly arbitrary menu items. Odd.

Interaction

As a KDE user I love krunner (a bit like Gnome-Do). So one my reactions is to hit alt-f2 when I want to run something.  I see that it starts up a smiliar dialog as hitting the button at the top left.  I started typing the name of the program I wanted to run, “kmail”, and it found it quickly.  I hit “enter” to run it but nothing happened.  I noticed that the kmail icon was not on the list of icons found any more!  I then noticed that if I backspace my input one character, so it says “kmai”, then the kmail icon appears again.  This must be a bug I guess.
I decided to have a play with the menu system a bit.  It seems a bit more work to find stuff than simply mousing around the K menu but I’ll keep trying it out and see how I get on.  My initial impression is that it needs some work though as it feels as though it’s trying to hide results for no reason until you click on “See N more results ?”.  I don’t understand why it doesn’t put a scroll bar up and show everything right away, I’m sure this would be quicker to navigate.
Dealing with windows:
  • The window controls have moved to the opposite corner.  Not a problem, but hard to get used to.
  • alt-tab selects windows that are not on the current virtual desktop.  This is *really* annoying :(
The final point to note today is that there appears to be no way to save my session and have it restored at login.  This is a feature I rely on extremely heavily in KDE and I am really sad to see it not available in Unity.
I hope to write ongoing reports over the next week or so.  I am actually away on holiday so it will be sporadic, but I’m sure I will find some moments.

Read more
Vincent Ladeuil

The package importer is an important piece of the Ubuntu Distributed Development. It mirrors source packages and Bazaar branches and relies heavily on Launchpad to achieve that.

The past

During Launchpad downtimes, many (>1000) imports failed and they had to be re-queued semi-manually. The importer would have been better inspired by making tea instead of queuing imports that were bound to fail.

The circuit breaker

An automatically operated electrical switch designed to protect an electrical circuit <…> a circuit breaker can be reset (either manually or automatically) to resume normal operation.

This looks like a good candidate to avoid import failures while Launchpad is down.

In this automaton representing the behaviour of a circuit breaker, three events are used (remember that here closed == works ;)):

  • attempt: we try to use the circuit,
  • failure: an undesired event has occurred,
  • success: the circuit is working.

The main scenario here is:

closed — failure –> open — attempt –> half open — success –> closed

The reality test

A Launchpad rollout happened Friday 30 September 08:32. The importer log file said:

2011-09-30 08:32:02,308 – __main__ – INFO – Launchpad is down, re-trying jcifs

2011-09-30 08:34:09,337 – __main__ – INFO – Launchpad *is* back

The successful import took 27″, so the importer knew Launchpad was down for 1’40″ (back – down – duration(import)). I asked the Launchpad admins how long it took them and their log said:

2011-09-30 08:33:41 INFO    Outage complete. 0:01:40.919527

Make tea… or not

Another interesting number here is that we retried 498 times during this downtime. This is probably excessive and can be fixed by reducing the importer concurrency while Launchpad is down. These 498 attempts were previously seen as failures for 498 different packages.

In the end, not only did we avoid these 498 spurious failures but the imports were only suspended for as long as Launchpad was down, up to the second !

But that’s a bit short to make tea…

Read more
David

Another edition of the Ubuntu App Developer Week and another amazing knowledge sharing fest around everything related to application development in Ubuntu. Brought to you by a range of the best experts in the field, here’s just a sample of the topics they talked about: App Developer Strategy, Bazaar, Bazaar Explorer, Launchpad, Python, Internationalization, Launchpad Translations, Unity, Unity 2D, Gedit Developer Plugins, the MyApps Portal, the App Review Board, the UbuntuSoftware Centre, Unity Mail, Launchpad Daily Builds, Ubuntu One APIs, Rapid App Development, Quickly, GooCanvas, PyGame, Unity Launcher, Vala, the App Developer Site, Indicators, Python Desktop Integration, Libgrip, Multitouch, Unity Lenses, Ubuntu One Files Integration, The Business Side of Apps, Go, Qt Quick… and more. Oh my!

And a pick of what they had to say:

We believe that to get Ubuntu from 20 million to 200 million users, we need more and better apps on Ubuntu
Jonathan Lange on making Ubuntu a target for app developers

Bazaar is the world’s finest revision control system
Jonathan Riddell on Bazaar

So you’ve got your stuff, wherever you are, whichever device you’re on
Stuart Langridge on Ubuntu One

Oneiric’s EOG and Evince will be gesture-enabled out of the box
Jussi Pakkanen on multitouch in Ubuntu 11.10

I control the upper right corner of your screen ;-)
Ted Gould on Indicators

If you happened to miss any of the sessions, you’ll find the logs for all of them on the Ubuntu App Developer Week page, and the summaries for each day on the links below:

Ubuntu App Developer Week – Day 5 Summary

The last day came with a surprise: an extra session for all of those who wanted to know more about Qt Quick and QML. Here are the summaries:

Getting A Grip on Your Apps: Multitouch on GTK apps using Libgrip

By Jussi Pakkanen

In his session, Jussi talked about one of the most interesting technologies where Ubuntu is leading the way in the open source world: multitouch. Walking the audience through the Grip Tutorial, he described how to add gesture support to existing applications based on GTK+ 3. He chose to focus on the higher layer of the uTouch stack, where he explained the concepts on which libgrip, the gesture library, is built upon, such as device types and subscriptions. After having explored in detail the code examples, he then revealed that in Oneiric Eye Of GNOME and Evince, Ubuntu’s default image viewer and default PDF reader, will be gesture-enabled.

Check out the session log.

Creating a Google Docs Lens

By Neil Patel

Neil introduced his session explaining the background behind Lenses: a re-architecture effort of the now superseded Places concept to make them more powerful, provide more features and make it easier to add features through a re-engineered API. Lenses create its own instance, add categories, filters and leave the searching to Scopes. The Lenses/Scopes pairs are purely requests for data, independent of the type of UI, and being provided by the libunity library, they can be written in any of the programming languages supported by GObject Introspection (Python, Javascript, C/C++, Vala, etc.). To illustrate all of this concepts, Neil devoted the rest of the session to a real example of creating a Lens for Google Docs.

Check out the session log.

Practical Ubuntu One Files Integration

By Michael Terry

Another hands-on session from Michael, with a real world example on how to supercharge apps with cloud support. Using his experience in integrating the Ubuntu One Files API to Deja Dup, the default backup application in Ubuntu, he went in detail through the code of a simple program to talk to a user’s personal Ubuntu One file storage area. We liked Michael’s session so much that it will very soon be featured as a tutorial on developer.ubuntu.com!

Check out the session log and Michael’s awesome notes.

Publishing Your Apps in the Software Center: The Business Side

By John Pugh

Ubuntu directly benefits from Canonical becoming a sustainable business to support its development, and that’s exactly what John talked about. Being responsible for business development in the Ubuntu Software Centre, he’s got a privileged  insight on how to make it happen. He started off explaining that the main goal is to present Ubuntu users with a large catalog of apps available for purchase, and then continued concentrating on how to submit paid applications to be published in the Software Centre. A simple 5-step process, the behind-the-scenes work can be summarized in: Canonical helps packaging the app, it hosts the app and provides the payment via pay.ubuntu.com, in a 80%/20% split. Other highlights include the facts that only non-DRM, non-licensed apps cannot be submitted right now, but there is ongoing work to implement license key support, and that MyApps, the online app submission portal, can take any nearly any content: apps with adverts, “free” online game clients and HTML5 apps.

Check out the session log.

Writing an App with Go

By Gustavo Niemeyer

Gustavo’s enthusiasm for Go, the new programming language created by Google shows every time you start a conversation with him on that topic. And it showed as well on this session, in which he created yet another “Hello world” application in a new language -you guessed-: Go. Along the way, he had time to describe all of the features of this new addition of the extensive family of programming languages: statically compiled with good reflection capabilities, structural typing, interfaces and more.

Check out the session log.

Qt Quick At A Pace

By Donald Carr

Closing the week on the last -and surprise- session, we had the luxury of having Donald, from the Nokia Qt team, the makers of Qt itself, to talk about Qt Quick. Using a clear and concise definition, Qt Quick is an umbrella term used to refer to QML and its associated tooling; QML being a declarative markup language with tight bindings to Javascript. A technology equally suited to mobile or to the desktop, QML enables developers to rapidly create animation-rich, pixmap-oriented UIs. Through the qtmediahub and Qt tutorial examples, he explored QML’s capabilities and offered good practices for succesfully developing QML-based projects.

Check out the session log.

Wrapping Up

Finally, if you’ve got any feedback on UADW, on how to make it better, things you enjoyed or things you believe should be improved, your comments will be very appreciated and useful to tailor this event to your needs.

Thanks a lot for participating. I hope you enjoyed it  as much as I did, and see you again in 6 months time for another week full with app development goodness!


Read more
David

Ubuntu App Developer Week – Day 4 Summary

Last day of UADW! While we’re watching the final sessions, here’s what happened yesterday:

Creating an App Developer Website: developer.ubuntu.com

By John Oxton and David Planella

Creating the concept and implementing a site for app developers is no easy task. The Ubuntu App Developer site is meant to be a place for app authors to get started with development, to find the information they need and to be able to publish their apps in the Software Centre. John explained all the research and user testing that happened behind the scenes, highlighting the key findings, while David focused on the purpose of the site, where it fits in the overall developer strategy for Ubuntu and the plans for the future.

Check out the session log here.

Rapid App Development with Quickly

By Michael Terry

Fitting nicely topicwise with the questions about the default choice of tools for Ubuntu development on the previous session, Michael gave an overview of what Quickly is and how to use it. Going through the workflow of creating your first app with Quickly, he demonstrated all the key commands and explained in detail all the bits in between.

Check out the session log here.

Developing with Freeform Design Surfaces: GooCanvas and PyGame

By Rick Spencer

Rick started off the session explaining what GooCanvas and PyGame were good for: providing a 2D surface on which to construct interactive GUIs for users. Beginning with GooCanvas, he showed with a very simple example how to get started playing with 2D composing surfaces, adding images, text and doing other operations such as resizing and calculating coordinates to determine clicks. Next up was PyGame, for the same purpose, but better suited for apps with lots of animation updates without user input. He then wrapped up with three samples of simple games to study.

Check out the session log here.

Making your app appear in the Indicators

By Ted Gould

Ted Gould, the man who controls the upper right corner of our screen, talked all about indicators. The idea was to illustrate how to get the information that comes from applications and handle it to the indicators. First up was the messaging menu, a menu to handle human-to-human communication, next the application indicators, which alllow long-running apps to put statuses on the panel consistently, and finally the sound indicator, taking care of all related to sound. Each one of them explained with code examples. Nice!

Check out the session log here.

Will it Blend? Python Libraries for Desktop Integration

By Marcelo Hashimoto

Marcelo shared his experience acquired with Polly, a Twitter client he developed, on using Python and libraries to let apps provide better integration to the desktop. First explaining the concept of desktop integration, stressing the fact that it’s not only about visuals. The rest of the session was structured around 3 main areas: how to send notifications to the user, where to place files read or written by an app and what to use to store sensitive information. A very clear and solid session, also with example code for easy learning.

Check out the session log here.

The Day Ahead: Upcoming Sessions for Day 4

Check out the first-class lineup for the last day of UADW:

16.00 UTCGetting A Grip on Your Apps: Multitouch on GTK apps using Libgrip

Multitouch is everywhere these days, and now on your desktop as well -brought to you by developers such as Jussi Pakkanen, who’ll guide through using libgrip to add  touch support to your GTK+ apps. Learn how to use this cool new library in your own software!

17:00 UTCCreating a Google Docs Lens

Lenses are ways of presenting data coming from different sources in Unity. Neil Patel knows Lenses inside out and will present a practical example of how to create a Google Docs one. Don’t miss this session on how to put two cool technologies together!

18:00 UTCPractical Ubuntu One Files Integration

Yet again the Deja-dup rockstar and UADW regular Michael Terry will be sharing his deep knowledge on developing apps. This time it’s about adding cloud support to applications: integrating with the Ubuntu One files API.

19:00 UTCPublishing Your Apps in the Software Center: The Business Side

Closing the series of sessions around publishing apps in the Software Centre, we’ll have the luxury of having John Pugh, from the team that brings you commercial apps into the Software Centre and who’ll be talking about the business side of things.

20:00 UTC – Writing an App with Go

Go is the coolest kid around in the world of programming languages. Gustavo Niemeyer is very excited about it and will be showing you how to write an app using this language from Google. Be warned, his enthusiasm is contagious!

20:00 UTC – Qt Quick At A Pace

A last minute and very welcome addition to the schedule. In his session Donald Carr will introduce you to Qt Quick to create applications with Qt Creator and QML, the new declarative language that brings together designers and developers.

Looking forward to seeing you all there!


Read more
David

Ubuntu App Developer Week – Day 3 Summary

Time flies and we’re already halfway through UADW, but there is still much to come! Here’s yesterday report for your reading pleasure:

Unity Mail: Webmail Notification on Your Desktop

By Dmitry Shachnev

Starting off with a description of the features of Unity Mail, such as displaying webmail unread message count, notifications and mail subjects, we then learned more about how it was developed and the technologies that were used to create it. It’s written in Python, using GObject introspection (PyGI) and integrates with Ubuntu through the Unity, Notify and Indicate modules. After describing each one in more detail, Dmitry continued talking about how the app can be translated using Launchpad, and how he uses the Bazaar  source revision control system to work with code history. Wrapping up, he went through the plans for the future: more configuration options, marking all messages as read and the need for a new icon. Any takers? ;)

Check out the session log here.

Launchpad Daily Builds and Rapid Feedback: Writing Recipe Builds

By Jelmer Vernooij

Assuming some previous knowledge on Debian packaging, in his session Jelmer walked the audience through a practical example of a basic recipe build for a small project: pydoctor. Drawing the cooking recipe analogy, package recipes are a description of the ingredients (source code branches) and how to put them together, ending up with a delicious Debian package for users to enjoy. Launchpad can build packages from recipes once or automatically on a daily basis provided the code has changed, conveniently placing the result in a PPA. In the last part of the session, he described in detail the contents of an existing recipe and added some notes on best practices when building from a recipe.

Check out the session log here.

Using the Ubuntu One APIs for Your Apps: An Overview

By Stuart Langridge

The idea bahind the Ubuntu One developer programme is to make it easy to add the cloud to your apps and make new apps for the cloud. With this opening line, Stuart delivered a talk about a high-level overview on the cool things you can do as an app developer adding Ubuntu One support. One aspect it data: for example building applications that work on the desktop, on mobile phones and on the web, securely sharing data among users. Another is music: streaming, streaming music and sharing playlists on the desktop, on mobile and from the web, all through a simple REST HTTP API. He also mentioned some examples of cloud enabled applications: Shutter and Deja-Dup, and many other interesting ways to use Ubuntu One to do exciting thigs with data. And you can get started already using the available documentation.

Check out the session log here.

Supercharging Your Apps with Unity Launcher Integration

By Jason Smith

In his talk, Jason first went through the terminology that covers the elements related to the Unity Launcher, and the bachground behind the Launcher API, implemented in the libunity library. Libunity can be used in many programming languages: Python, C, Vala and others supported by GObject Introspection. Going through what you can do with the Launcher (marking/unmarking apps as urgent, setting object counts, setting progress on objects and adding quicklist menu items to the object), he used Vala snippets to illustrate each feature with code.

Check out the session log here.

Hello Vala: An Introduction to the Vala Language

By Luca Bruno

Vala, a new programming language with C#-like syntax that compiles to C and targets the GObject type system: with a clear statement of what Vala is and what it can do, Luca, a contributor to the project introduced one by one the mostkey features of the language through his “Hello world” example: namespaces, types, classes, properties, keywords and more. As a highlight he mentioned Vala’s automatic memory management using reference counting, andits interoperability with other languages, most notably C, but it can also work with many others supported by GObject Introspection. Other cool featuresto note were also error handling on top of GError, support for async operations, closures and DBus client/server, on each of which he elaborated before finishing the session.

Check out the session log here.

The Day Ahead: Upcoming Sessions for Day 3

Another day, another awesome set of sessions coming up:

16.00 UTCCreating an App Developer Website: developer.ubuntu.com

Ubuntu 11.10 will not only bring new features to the OS itself. In time for the release we’ll be launching the new Ubuntu App Developer site, a place for developers to find all the infromation and the resources they need to get started creating, submitting and publishing their apps in Ubuntu. John Oxton, David Planella and many other people have worked to make the next developer.ubuntu.com possible and will tell you all about it.

17:00 UTCRapid App Development with Quickly

Quickly is a wrapper that pulls together all the recommended tools and technologies to bring apps from creation and through their whole life cycle in Ubuntu. With an easy set of commands that hide all the complexity for your, it effectively enables developers to follow rapid development principles and worry only about writing code. Michael Terry, from the Quickly development team will be looking forward to guide you through the first steps with this awesome tool.

18:00 UTCDeveloping with Freeform Design Surfaces: GooCanvas and PyGame

Have you ever wondered what freeform design surfaces, or canvases are? You probably have now. Well, lucky you then, because Rick Spencer will be here to tell you what they’re good for and how to get started with them ;)

19:00 UTCMaking your app appear in the Indicators

In another session on how to integrate with the platform, Ted Gould, the man who knows most about them, will describe how to add indicator features  to your apps, both in terms of panel indicators and messaging menu support.

20:00 UTC – Will it Blend? Python Libraries for Desktop Integration

You certainly will want your app to have that familiar look and feel at home in the OS it’s running on, but you’ll also want it to use all the backend technologies to integrate even deeper and provide a great user experience. Well, fear not, for Marcelo Hashimoto is here to tell you exactly how to do that!

Looking forward to seeing you all there in a few hours!


Read more
David

Ubuntu App Developer Week – Day 2 Summary

Another app developer day is over and we’re nearly halfway through the week. Here’s what happened yesterday:

Making Your App Speak Languages with Launchpad Translations

By David Planella

In this session we learned how to link up an app that already has internationalization support to Launchpad Translations, so that it is exposed to Launchpad’s extensive community of translators who’ll effectively make your app speak almost any language. From setting up code hosting for a seamless integration, to setting up the translations settings to tips and tricks for best practices, the presentation should give developers a good grasp of how to start getting their apps translated and ready to reach a wider audience.

Check out the session log here.

The Making of Unity 2D

By Florian Boucault

An interactive and popular session, in which Florian started describing the main goal behind the Unity 2D project: to run on platforms that do not provide accelerated OpenGL. It essentially is an implementation of the main Unity user interface using the Qt toolkit and the QML declarative language, while reusing the backend technologies from Unity. From there he went on describing the Unity 2D architecture and the release policy, pointing out to the Unity 2D daily PPA, for those testers who want to be on the bleeding edge., and wrapped up answering the questions from the audience.

Check out the session log here.

Making App Development Easy: Gedit Developer Plugins

By Curtis Hovey

Starting off with a description of Gedit plugins, their purpose and how to install them, Curtis delved into the general-purpose plugins and the developer plugins (click to install) plugins, explaining how to set them up and his recommended choice of plugins to convert Gedit in the perfect programming editor. The highlights included the GDP Bazaar integration plug in, which allows working with the bzr source revision control system and others (Subversion, Mercurial, Git), as well as the Source Code Browser plugin, a class and function browser based on Exuberant Ctags.

Check out the session log here.

Publishing Your Apps in the Software Center: The MyApps Portal

By Anthony Lenton

In another session devoted to the app developer strategy, Anthony told us all about the MyApps webapp developers can use to submit their applications to the Software Center. Available on https://myapps.developer.ubuntu.com, it started off as the need to automate the submission of commercial apps to the Software Centre, expanding to a full-blown online portal that can now tackle any type of submission. He then walked the audience through the 5-step process to send an app for review, including all the necessary metadata and payment details. Once an app has been submitted, it needs to be packaged (if it wasn’t already) and reviewed before being published. Hinting to Jonathan Lange’s session on day 1, Anthony explained that they are looking at providing an automated process for packaging, with the intention of removing the last big remaining manual process.

Check out the session log here.

Publishing Your Apps in the Software Center: The App Review Board

By Stéphane Graber

Complementing the previous session, Stéphane explained how libre+gratis apps can get into the Software Centre and what the App Review Board’s (ARB) role is in that process. He focused on how the Board reviews applications and how other types are distributed in Ubuntu. The types of apps reviewed by the ARB are small, lightweight apps, usually of the type created by Quickly (check out the sessions on Quickly on Thursday!). The next upcoming changes in the way this applications are reviewed will most probably include them being submitted through the MyApps online portal and them being made more secure by wrapping them in a container based on AppArmor or Arkose (or a combination of them).

Check out the session log here.

The Day Ahead: Upcoming Sessions for Day 3

Check out today’s rocking lineup:

16.00 UTCUnity Mail: Webmail Notification on Your Desktop

We’re starting to see more and more apps that integrate with Unity. Unity Mail is a cool app that allows you to stay up to date with your web mail directly from your desktop. It supports any IMAP server, but right now it works best with Gmail, along with notifications, message counts, quicklists and more. Dmitry Shachnev will tell us about its features and how he put the application together.

17:00 UTCLaunchpad Daily Builds and Rapid Feedback: Writing Recipe Builds

Launchpad has many awesome features. This time around Jelmer Vernooij will be explaininghow to set up recipe builds for your project in Launchpad, so that users can get  the latest updates easily packaged on a daily basis, so that they can install them at a click of a button and can test them and make the feedback loop as short as possible.

18:00 UTCUsing the Ubuntu One APIs for Your Apps: An Overview

Ubuntu One is starting to be everywhere, and it even has its own developer programme. The Ubuntu One website already provides lots of information to developers, and to make it even more clear, Stuart Langridge will walk you through the available Ubuntu One APIs you can use to make your application cloud-ready.

19:00 UTCSupercharging Your Apps with Unity Launcher Integration

One of the easiest and more visual ways for your apps to blend in with Unity is for it to integrate with the Launcher. Counts, progress indication, quicklists… are an elegant and simple wayto provide feedback to users. Jason Smith knows all about Launcher integration, and he’s really looking forward to share it with us!

20:00 UTC – Hello Vala: An Introduction to the Vala Language

Vala is a powerful programming language that allows modern programming techniques to be used to write applications that run on the GNOME runtime libraries, particularly GLib and GObject. Luca Bruno is part of the team that develops Vala itself, and will be introducing us to the first steps to get started with Vala with the universal “Hello world” app becoming “Hello Vala!”.

Looking forward to seeing you all there in a few hours!


Read more
David

Ubuntu App Developer Week – Day 1 Summary

The first day of Ubuntu App Developer Week is over and we’re ramping up to day 2! A great start and lots of interest in the audience. Here is a small summary from yesterday’s schedule.

Making Ubuntu a Target for App Developers

By Jonathan Lange

Jono, who has recently started working on the Ubuntu developer programme after having been developing and defining the strategy on Launchpad for the last 5 years, started off explaining that to cross the chasm and to get our OS from 20 million to 200 million users, we need more and better apps on Ubuntu. There are some key aspects to this goal, coinciding with areas of ongoing work:

  • A place – making some place that app developers can go to in order to learn how to develop for Ubuntu (developer.ubuntu.com)
  • A definition – defining a platform for developers to target
  • A channel – a smooth, short, safe path from developers to their users and back again (the Ubuntu Software Centre and MyApps)

After expanding on the subjects of automatic packaging and security, the conclusion is that with all of these pieces in place -Software Centre, developer portal, a defined platform, automagic packaging, safe mechanisms for distributing new apps & paying developers- then Ubuntu becomes something that developers can seriously start to target

Check out the session log here.

Introducing Bazaar Explorer: Version Control for your Apps

By Jonathan Riddell

“Bazaar is the world’s finest revision control system” – an awesome quote to start an equally awesome session. With this, and with the idea that Bazaar needs to be available to anyone, not only to those already comfortable with the command line, Jonathan Riddell provided a tour of the most feature-rich GUI for Bazaar. Illustrating the most common commands for everyday use and with plenty of pictures, he provided an excellent overview of how this powerful, cross-platform, graphical interface for bzr can make life much easier to app developers.

Check out the session log here.

Your App & Launchpad best practices

By Jason DeRose

Jason’s session on how to make the best use of Launchpad, the online collaboration and hosting suite for your projects, was structured around 3 central points: 1. Why should you host your project in Launchpad? To which his answer was: because PPAs, daily builds and lots of users; 2. How to set up your app to use Launchpad, where he guided participants through the process of creating a Launchpad project and offering some insights on best practices. Finally, on 3. Using Launchpad to engage developers he wrapped up with a series of recommendations and tips to ease and foster contributions to your project. More on the session log :)

Check out the session log here.

Getting Started With Python: a Hello World App

By Alan Bell

As a grand finale to the day, Alan delivered a beginner-friendly session on the basics of the Python programming language. Assuming no prior knowledge, he walked participants through the classical “Hello world” example in Python, which universally greets programming novices on the terminal with a friendly welcome message. Along the way, he explained in detail all the extra bits to make this simple application run and be useful as a kickstart to becoming a full-blown Python programmer.

Check out the session log here.

The Day Ahead: Upcoming Sessions for Day 2

More app development goodness for fun and profit: here’s today’s schedule.

16.00 UTCMaking Your App Speak Languages with Launchpad Translations

Did you know that along with code hosting, release management, bug tracking and support, you can also use Launchpad to get your app translated?. David Planella will explain you how to set up your app in Launchpad for translations and give you some advice on building a translator community around it.

17:00 UTCThe Making of Unity 2D

Unity needs to run on every type of desktop, from those with powerful 3D graphics processors to those only able to run in 2D. Unity 2D was born out of the need to provide a near identical experience as its 3D counterpart on systems which cannot rely on 3D graphical processing, such as ARM computers. Florian Boucault will talk about what Unity 2D is, how it was designed, and the technologies used to implement it.

18:00 UTCMaking App Development Easy: Gedit Developer Plugins

Gedit is Ubuntu’s lightweight yet powerful default text editor. Its flexible plugin architecture means that it can easily be extended to meet any need. Curtis Hovey will guide you through his Gedit Developer Plugins to help you convert a general-purpose editor into the perfect programming editor.

19:00 UTCPublishing Your Apps in the Software Center: the MyApps Portal

Canonical is taking app developers very seriously,and one of the important aspects of ensuring a smooth workflow for submitting and publishing applications into the Ubuntu Software Centre is providing the right set of tools. Anthony Lenton will tell you the story behind the MyApps tool and how app authors can use it to submit their apps.

20:00 UTC – Publishing Your Apps in the Software Center: The App Review Board

If you are an open source developer and want to publish your libre + gratis app into the Ubuntu Software Centre, the App Review Board (ARB) will take care of reviewing it, ensuring it is up to the Ubuntu standards and help you publishing it for all users to install. Stéphane Graber is a member of the ARB and will explain how the Board works and the steps to successfully submit an app for review.

Looking forward to seeing you all there in a few hours!


Read more
rsalveti

As at Linaro we usually work with many PPAs over the releases, there was a need to generate a proper changelog for a PPA, in a way we could know what packages got changed before doing the release.

At first I thought I could just parse the repository metadata (as a PPA is nothing more than a debian repository), but then I realized I could just use the awesome (yes, *awesome*) launchpadlib, if it had a way to get the data I needed.

So I called the launchpadlib master I know (Ursinha), and in 15 minutes we saw that we could use it to parse the “.changes” file, and from there get the data I needed. As Launchpad stores the PPA packages publishing history, it’s quite easy to get all the changes over period of time.

A few minutes later (after also noticing that there’s a python-debian module to parse the changes file), I created the first version of the generate-ppa-changelog.py script, that does exactly what I needed, and with just a few python lines :-)

Here’s the link: http://bazaar.launchpad.net/~rsalveti/+junk/launchpad/view/head:/generate-ppa-changelog.py.

Usage:

rsalveti@evatp:~/projects/launchpad/scripts$ python generate-ppa-changelog.py -h
usage: generate-ppa-changelog.py [-h] [-d YYYYMMDD] [-s SERIES] -t TEAM
[-p PPA] [–version]

Print Changelog for a PPA

optional arguments:
-h, –help show this help message and exit
-d YYYYMMDD, –date YYYYMMDD
start date to probe for changes
-s SERIES, –series SERIES
ubuntu series to look for changes (default: natty)
-t TEAM, –team TEAM launchpad team that owns the PPA
-p PPA, –ppa PPA ppa name to probe the changelog (default: first PPA)
–version show program’s version number and exit

If no argument is given, it will probe all the changes for the default series.

Output Example:

rsalveti@evatp:~/projects/launchpad/scripts$ python generate-ppa-changelog.py -t linaro-maintainers -p overlay -s natty -d 20110701
Changelog for linaro-maintainers’s overlay PPA (series natty) since 2011-07-01 00:00:00

base-files (5.0.0ubuntu28linaro3) natty; urgency=low

* Updating Linaro LEB version to 11.07 (development branch)

— Ricardo Salveti de Araujo Fri, 15 Jul 2011 04:19:40 -0300

libjpeg-turbo (1.1.1-1inaro2) natty; urgency=low

* release
* add timestamp code to cjpeg.c
* default cjpeg.c and djpeg.c timestamp code to off

— Tom Gall Mon, 11 Jul 2011 20:32:23 +0000

linaro-meta (017) natty; urgency=low

* Refreshed dependencies
* Added libjpeg-turbo62 to linaro-alip, linaro-graphical-engineering,
linaro-multimedia-engineering, linaro-ubuntu-desktop

— Tom Gall Wed, 13 Jul 2011 15:41:29 +0000

u-boot-linaro (2011.07.1-0ubuntu1~natty1) natty; urgency=low

* New upstream 2011.07.1 which includes
– PXE FDT fix from previous ubuntu release so patch has been removed
– Added missing PXE env vars (LP: #808815)
– Generated unique usbethaddr (LP: #809015)
– Modify pxe command to look for usbethaddr if ethaddr is NULL

— John Rigby Wed, 13 Jul 2011 23:31:39 -0600

x-loader (1.5.1+git20110715+fca7cd2-1ubuntu1~natty1) natty; urgency=low

* New upstream release
– several fixes for panda and igep
– OMAP3 code cleanup
– Beagle Rev C5 support
– Support for IGEPv3 board

— Ricardo Salveti de Araujo Fri, 15 Jul 2011 05:55:09 -0300

x-loader (1.5.0+git20110714+cdc887b-1ubuntu1~natty1) natty; urgency=low

* New upstream release
– Adding support for IGEPv3 board
* debian/patches/01-Beagle-Rev-C5-support.patch:
– Adding support for the new Beagle C5

— Ricardo Salveti de Araujo Fri, 15 Jul 2011 02:36:58 -0300

And now we can just generate the proper changelog anytime we want to do a call for testing or a Linaro Ubuntu release :-)


Read more
David

After the first language packs have now been generated, I am pleased to announce that our current development release, Ubuntu Oneiric, is now open for translation:

Translate Ubuntu Oneiric!

  • Translation schedule. Remember that according to the release schedule translatable messages might be subject to change until the User Interface Freeze on the week of the 25th of August.
  • Language packs. During the development cycle, language packs containing translations will be released twice per week except for the freeze periods. This will allow users and translators to quickly see and test the results of translations.
  • Test and report bugs. If you notice any issues (e.g. untranslated strings or applications), do check with the translation team for your language first. If you think it is a genuine bug, please report it.
  • Learn More. Learn how to start translating Ubuntu and enable millions to use it in their language.

open 19 image by loop_oh – License: CC by-nd 2.0


Read more