Canonical Voices

Posts tagged with 'launchpad'

pitti

The Debian import freeze is settled, the first rush of major changes went into Maverick, and the dust now has settled a bit. Thus it’s time to turn back some attention to crashes and quality in general.

This morning I created maverick chroots for the Apport retracers, and they are currently processing the backlog. I also uploaded a new Apport package which now enables crash reporting by default again.

Happy segfaulting!

Read more
David

This post is password protected. To view it please enter your password below:



Read more
Michael

Thanks to the excellent work from the Launchpad Code team and others (James and William, to name just two), here’s a preview of how easy it will soon be to build a branch into published binaries in your PPA:

http://blip.tv/file/3738068

(I’ll update with the inline flash version once it’s been converted).


Filed under: launchpad

Read more
Tim Penhey (thumper)

Launchpad code update

We've been very busy over the last couple of months with lots of changes that most people will never notice.

Reduced latency


Branches pushed to Launchpad are now immediately available over http to anonymous readers of the branch, which includes the loggerhead code browser.

Code review email changes


When proposing a branch for review the initial emails and subsequent comments will now come in order. Previously if someone commented before the script that generated the diff was run, the comment would be emailed out first, now it isn't.

Teams requested to review now get email


Everyone in the team that is requested to review will get email now. This is a blessing for those that want it, and almost a curse for those that aren't interested. Launchpad adds a number of email headers to help users with filtering of email. Here is an example from an email I received:


X-Launchpad-Message-Rationale: Reviewer @drizzle-developers
X-Launchpad-Notification-Type: code-review
X-Launchpad-Project: drizzle


Since it was a team that was requested to review, there is the @drizzle-developers added to the X-Launchpad-Message-Rationale. If I was personally asked to review, the header would just say Reviewer.

Build branch to archive


This was the original name of the feature, but it is more about recipes now. A recipe is a collection of instructions on how to build a source package. We are still testing this internally, but I'm hoping to get this enabled on edge very soon. This will be extended to add daily builds.

What does this really mean?

Lets say you want to have a daily build of a project, like gwibber. You would then create a recipe that uses trunk as a base branch, merge in the packaging info, and say "Please build this every day into my PPA". And Launchpad will.

Read more
David

????As most of you know, we’ve got an amazing translations community in Ubuntu. Every day, hundreds of translators use Launchpad Translations as a tool to make our OS of choice available in almost any language.

As such, I’m thrilled to announce a set of GSoC projects focused on Launchpad Translations and aimed towards improving the Ubuntu translations community experience.

Here they are:

Projects

Package set views in Launchpad Translations

Currently we expose the full list of translations in the main archive to Ubuntu translators. This is generally overwhelming for new translators and it does not show accurate statistics on how well translated a distribution is. It would be useful to have a global view of projects or modules which would only include the templates which are part of them (e.g. Ubuntu, Kubuntu, UNR, or even further granularisation in subprojects or most important upstreams: GNOME, KDE, etc.). This could be e.g. modelled after the package sets already available from Launchpad.

Full Launchpad Translations API

The aim of this project is to implement a full API for the Launchpad Translations component. This will allow accessing translations-related data from Launchpad through launchpadlib. The API can be subdivided in several components (e.g. reporting -already being developed-, imports queue, translations, etc.) and will open the door to a broad range of uses of Launchpad Translations: more automated management of Ubuntu translations, automated status tracking of imports by users, client-side online translation, navigation of the site in custom applications, requesting downloads, fetching individual messages or suggestions, etc.

Native support for OpenOffice.org translations format in Launchpad Translations

Launchpad Translations standardizes on using the Gettext PO format for importing and exporting translations. While this covers the majority of Open Source projects supporting localization, there are a couple of notable exceptions. These implement custom formats and cannot be directly imported or exported. OpenOffice.org is one of them. Its custom GSI/SDF translation format needs to be converted to gettext before importing it into Launchpad. This causes quite a lot of packaging overhead and manual work, and the translations cannot use the language pack infrastructure. Due to this, we had to recently disable OpenOffice.org translations in Launchpad. We want Ubuntu translators to be able to translate OpenOffice.org in Launchpad as any other Ubuntu package and to be able to contribute translations back to upstream. The aim of this project is to implement native support for importing and exporting OpenOffice.org’s GSI/SDF translation format.

Full native support for Mozilla translations format in Launchpad Translations

Launchpad Translations standardizes on using the Gettext PO format for importing and exporting translations. While this covers the majority of Open Source projects supporting localization, there are a couple of notable exceptions. These implement custom formats and cannot be directly imported or exported. Firefox uses the custom XPI translations format and is one of them. While native import support is already implemented and functional, translations are currently exported in an intermediate format and the conversion back to XPI is done outside of Launchpad. We want the Ubuntu Mozilla translations to be exported in native format and be able to use them directly in language packs and allow contributing the translations back to upstream. The aim of this project is to complete the support for the Mozilla translation format and enabling native export.

Native support for XML documentation in Launchpad Translations

Launchpad Translations standardizes on using the Gettext PO format for importing and exporting translations. This generally covers the majority of Open Source projects supporting localization, but only their user interface. Documentation is generally produced in other formats (mostly docbook) and must be converted to the Gettext PO format before importing it into Launchpad and converted back to XML upon export. This additional step, generally performed by tools such as `xml2po` or `po4all` currently stops us from importing documentation of upstream projects for translation in Launchpad in Ubuntu. The aim of this project is to implement native XML support for translatable documentation in Launchpad Translations, so that it can be seamlessly imported and exported.

Adding POT template generation support for layouts other than intltool in Launchpad Translations

Upstream integration is the current development focus in Launchpad. To that end, the Launchpad Translations component is being extended to enable translation imports directly from bzr branches of upstream projects. One important aspect of this feature is the automatic regeneration of POT translation templates from the branches, which is implemented using what is internally called the pottery infrastructure. Pottery currently supports the intltool layout, which already covers a great number of Open Source projects. However, there will still a percentage of upstream projects which do not follow this standard intltool layout. The aim of this project is to extend pottery to support additional formats, so that the maximum number of upstreams can be imported into Launchpad Translations.

So, you’d like to work on this?

Danilo Šegan, the Launchpad Translations team lead, will be the mentor for these projects, but you can use me as a backup contact as well, especially this week, as Danilo is away on a coding sprint.

You’ll find all the information you need on Ubuntu’s participation in the GSoC 2010 and how to get involved here:

So here’s your chance of joining the team of Launchpad developer legends and making the Ubuntu translation experience even more awesome.

If you are wondering what all this is about, here is some content to get you started:

And if you’ve got any questions, feel free to ask!


Read more
Michael

Having just been through the process of trying to involve people in open source design and development, Maris Fogels (another Launchpad engineer) and I took some time to document/reflect on the process. The strongest point that came out of the Q&A for me is the importance of voice conversations for iterating a design like this.

In this Q&A Michael shares his experience helping design the ‘Build Branch to Archive’ user interface:

Ubuntu is beginning to manage its source packages as Bazaar branches, as part of the DistributedDevelopment project.

One incredibly important activity for source packages is building them into binary packages that can be downloaded and installed. This spec explains how Launchpad can make this a wonderful experience.

Mars: Have you done any work designing user interfaces before this?

Michael: A little – we went through a similar process for the PPA redesign as
part of Launchpad 3.0. Prior to that, no, only your typical “Oh this
needs a UI – let’s just start creating the UI that *we* think the
target users will want.”

We had tried (in the Launchpad Soyuz team) doing something similar to
this design process previously (particularly, defining stories for an
interaction before coding, and getting feedback from the people
representing the target users), but no matter how hard we tried, we
weren’t able to get the time with them or any feedback, and so we
ended up implementing the design and landing it without their
feedback, which was a mistake – and a lesson learned which influenced
the process I used here.

Mars: What tools and resources did you use as you went through the project?

Michael: Balsamiq, wikis, email discussions and phone calls. Balsamiq was great
as a way to create UI’s quickly, modify them easily as we learned
more, share them for others to modify (I just pushed a bzr branch that
I kept up to date).

Mars: Was there a particular process that you followed?

Michael: Basically I tried to:

  1. Identify and describe the use-cases,
  2. Create mockups for each use-case,
  3. Get feedback from as many people as possible,

and then constantly update or add new use-cases and mockups as more
info came in. Looking back, it seems we went through three definite
iterations.

Mars: How long did it take to design the page?

Michael: We just designed the main interactions to build a branch into a PPA,
which is 2 pages/overlays (they’ll be overlays if js is enabled). I
think the process (3 iterations above of gathering feedback,
phone-calls etc.) spanned 3 weeks, on and off.

Mars: Do you think the problem was well-understood before you started working on the user interface?

Michael: I think different people understood their own domains of the
build-from-branch interaction, and everyone had ideas about how the
other parts should work, but no, I don’t think any of us understood
the use-cases properly – particularly the issues around re-using
recipes in the UI – until all the ideas and feeback was collected and
put together.

Mars: Did the design of the interface change much as work progressed?

Old vs. New

Michael: Yes, quite a bit. Initially I had initially (mis)understood that we
needed to work with the current implementation of bzr-builder, but
after the first iteration, James Westby pointed out that bzr-builder
can be updated to support the requirements of the UI. This freed us to
consider sharing recipes in the UI in a way that would not have been
possible otherwise.

Collecting and expanding the use-cases naturally required updates to
the design. Also feedback and questions from various people helped to
keep refocusing on what people want to be able to do (for example,
“This recipe supports building to Ubuntu Lucid, Ubuntu 9.10 and Ubuntu
9.04″, while still allowing the person using the recipe to select just
the distroseries they want).

Mars: How did you get feedback on your designs? Was there a good response?

Michael: (Just an aside, there’s no ‘y’ there – they are really our designs, I
was just filtering and focusing the collected thoughts and ideas into
something visible).

So as above, email to the dev list, then irc chats, but the biggest
throughput of communication and feedback came via actual calls. It’s
just so much easier to clear misunderstandings on the spot if you walk
through the process together. I had multiple calls with 6 different
people, all which were invaluable.

Mars: Looking back, what was the most difficult part of the process?

Michael: (1) Getting real user input and feedback and (2) getting feedback from
professional designers.

With (1) the best I could do with the time I had was to communicate
with representatives of target users, which I think worked quite well.
And (2) was difficult mostly due to the nature of the problem for
build-from-branch. IMO it requires someone to sit physically in the
office and walk through the process with a designer, something I
couldn’t do, and hasn’t been done yet as far as I know.

Mars: What did you most enjoy about the work?

Michael: Bringing lots of ideas together from lots of people, clarifying the
different needs to different people to build a common understanding of
the issues involved.

But, to be honest, I am also enjoying getting back to soyuz coding. I
enjoy doing this kind of thing for a week or two, but after that I’m
always keen to get back to doing some coding.

I think I (and James?) also enjoyed the fact that we could work on
defining the interaction *before* anything had been coded. Too often
we get in there and just start coding something without thinking
through the use-cases properly (or even defining them), and it ends up
causing a lot of pain. Like everything, it’s a learning process.

Mars: Any final words for developers looking to try this themselves?

Michael: Sure, if you’d like a change of rhythm and enjoy facilitating
conversations and ideas, give it a go – it’s a great chance to
interact with other people in different areas and build your
understanding of what people actually want to do with your product.


Filed under: design, launchpad

Read more
Michael

Every time that I upgrade my operating system, I feel like I’m receiving a whole bunch of gifts from people I don’t know – which actually is what’s happening! As I learn more about the Debian and Ubuntu communities, and Launchpad (which I’ve been working on for the past year), I never stop feeling awed at the amount of effort that is being filtered through Launchpad (in both directions) in terms of bug-fixes, new packages, translations etc., into end-products that rock!

Having upgraded my netbook a few weeks ago, over the weekend I decided to upgrade my work machine to test the latest development release, Ubuntu Lucid, and the only difficult part of the process was having to install Windows XP to update my bios (because Samsung, the manufacturer of my work laptop, only provide bios updates as win-32 applications). Other than that, it’s been a joy seeing all the improvements (like the open-source nvidia support – a few clicks and my dual monitors worked perfectly, something I could only do previously with the proprietary drivers).

So, whether it is heard or not, I want to say a big thanks to the millions involved for the gift – my Lucid experience has been wonderful.


Read more
Tim Penhey (thumper)

Trivial bugs

This is just a quick note really. One thing I've been trying to do more and more is to address simple bugs in a more timely manner.

I use the tag "trivial" to indicate to me that the bug is very simple to fix. By this I mean that I should be able to have the fix and the test all written in under an hour, and normally under 30 minutes.

Personally I'm (hopefully) fixing one trivial bug a day in addition to other work. This way the simple bugs get some attention, and I get the feeling of accomplishing something when other things are in the pipeline that take longer to get completed.

My scheduling of trivial bugs is somewhat arbitrary. Often the most recently commented on trivial bug will get my attention.

Read more
Gerry Carr

We are pleased to announce the launch of the brand new Ubuntu single sign on service.  The goal of this service is to provide a single, central login service for all Ubuntu-related sites, thus making it more convenient for Ubuntu users and community members to access information, communicate, and contribute.  This service will replace the existing Launchpad login service that is currently in use for many Ubuntu-related sites, although existing Launchpad accounts will continue to work in the new service.

Over the next few months we will be moving all of the Ubuntu and Canonical related sites that currently use the Launchpad service to Ubuntu single sign on, starting with sites we manage directly and then working with community site owners to move the community-managed sites.

Because of the number of existing Ubuntu users who have created accounts in Launchpad for the purpose of logging into other sites, we have set the Ubuntu and Launchpad services to share account data during the transition.  Launchpad is in the process of enabling users to log in with an Ubuntu account and, once completed, this sharing will be removed.  This does mean that you will be able to log into both services with the same credentials for a while.  We realise this is something internet users have been encouraged to not do but it is a necessary side-effect of the transition.  Doing this ensures you won’t lose access to services you’ve purchased from us in the past or your account histories in the sites you’ve previously visited, as long as you use your existing Launchpad credentials on Ubuntu single sign on.

Ubuntu single sign on is built on OpenID so, once all the sites we know about have moved over, we will also be opening up the OpenID service to enable you to log in to any site which accepts standard OpenIDs.

Some questions we think you may have for us:

Why replace the Launchpad login service?

The Launchpad login service has served us well for several years but Launchpad is not a familiar brand for many Ubuntu users.  As Ubuntu grows, we’ll see more and more users who don’t understand the connection between Launchpad and Ubuntu and the new Ubuntu login service is intended to overcome this problem.  It will also enable us to develop features which are more oriented to Ubuntu users.

How does the new service differ from the old one?

For now, not much apart from the appearance of the site.  We have many plans for great new features, however, and hope to roll these out once the service is established.  If you have ideas for other features you’d like to see in Ubuntu single sign on, we’d love to hear about them.

Is the new service Open Source?

No, it’s not.  It is, however, built and hosted on open source technologies (python, django, apache and postgres amongst others).

I have a problem with the new service.  Where can I get help?

We have an email support channel.  You can submit your support requests using our support form.  If you have found a bug, please take a few minutes to tell us about it on Launchpad.

We’re sure you have more questions.  Please submit them and we’ll do our best to respond to them all.

Stuart Metcalfe, Infrastructure Systems Development, Canonical

Read more
Martin Pool

Review of Launchpad and Bazaar on ArsTechnica by the lead developer of gwibber.

  • Likes the way the bzr client feeds into the web ui, by setting bug links etc
  • Easy automatic imports from cvs, svn, git and hg, either for a one-shot cutover or continuing tracking
  • More powerful bug tracking than github
  • Loggerhead feels slow and poorly integrated with Launchpad, but qbzr is brilliant
  • Merge proposals good for tracking contributions

Read more
bigjools

As the lead on the Launchpad Soyuz project, I have to deal with a lot of different tasks at the same time.  I hate this as much as the next engineer, but burying my head in the sand and hoping things will just be all right simply won’t work.

At the end of the day I was feeling really unproductive and anxious about time wasted – I’d sit back and think, what did I do today?  I felt really busy but I can’t remember what the heck I’ve been doing! Even worse, I’d leave my office at the end of the day in a bad mood and the 30 seconds it takes to get back into the house is not enough to ease the tensions, which made it hard to interact with my wife and kids.  I want to reclaim that precious hour between finishing work and the kids going to bed!

So, what can I do about this?

Three things:

1. I made a conscious effort to finish my major work items 30 minutes before leaving the office and to spend those 30 minutes doing all the simple tasks that you know you need to sort out but never get around to doing.  This has had a dramatic affect on not only how I feel when I finish, but also I get the warm fuzzy feeling of having cleared out stuff that was niggling me at the back of my brain.

2. I have eschewed technology in favour of the classic pen and paper!  I used to keep TODO lists electronically, but I found this hard to keep up with as they were always hidden by other windows on another virtual desktop somewhere.  So now,  each week I start on a fresh piece of paper and write down all the things I know I need to do, with a little box next to them.  When I’ve done that task, I can put a great big satisfying tick next to it.  At the end of each day I can see visible progress.  This is very uplifting!  I start a new sheet each week so that the TODO list is not cluttered, and it also forces me to think of anything I missed.

3. Take regular breaks.  I know, this is easier said than done.  Michael Nelson put me on to the Pomodoro Technique which while I don’t follow religiously, does give some effective tips on how to time-box your activities.

If you’ve got any more tips, or used mine and found them useful, I’d love to hear about it!  Please leave a comment.


Read more

We’ve used Windmill in our Launchpad buildbots for a while now, and it’s actually worked out quite well. I was afraid that we would have a lot of fallout, since in the beginning Windmill was fragile and caused a lot of intermittent test failure. However, so far I’d said that we’ve had very little problems. There was one intermittent failure, but it was known from the beginning that it would fail eventually. Apart from that we’ve had only one major issue, and that’s that something is using 100% CPU when our combined Javascript file is bigger than 512 000 bytes. This stopped people from landing Javascript additions for a while, and we still haven’t resolved this issue, apart from making the file smaller.

There are some things that would be nice to improve with regards to Windmill. The most important thing is to make sure that launchpad.js can be bigger than 512 000 bytes:

It would also be nice to make the test output nicer. At the moment Windmill logs quite a lot to stderr, making it look like the test failed, even though it didn’t. We don’t want Windmill to log anything really, unless it’s a critical failure:

I was going to say that we also have some problems related to logging in (because we look at a possibly stale page to decide whether the user is logged in), but it seems like Salgado already fixed it!

It would also be nice to investigate whether the problem with asserting a node directly after waiting for it sometimes fails. We had problems like that before; code was waiting for an element, and when using assertNode directly after the wait, the node still didn’t exist. I haven’t seen any test fail like that lately, so it might have been fixed somehow:

There are some other things I could think of that would be nice to have. I haven’t found any bugs filed for them, but I’ll list them here.

  • Don’t run the whole test suite under xvfb-run. It’d be better to start xvfb only for the Windmill tests.
  • Use xvfb by default for Windmill tests. When running the Windmill tests it’s quite annoying to have Firefox pop up now and then. It’d be better to run them headless by default.
  • Switches for making debugging easier. Currently we shut down Firefox after running the Windmill tests. It should be possible to have Firefox remain running after the test has finished running, so that you can manually poke around if you want to. If we use xvfb by default, we also need a switch for not using it.

Read more
Michael

A few weeks ago at our Launchpad BuildFromBranch sprint, I gave a brief overview of the process I use when doing a significant design change – whether it’s a code architecture or UI design (hint: don’t try to do a presentation after flying for 26 hours with two kids).

The main point that I was keen to communicate is how important it is to involve people and get early feedback. Launchpad bugs provide a great way to invite this involvement too, as you’ve already got many of the interested people already subscribed, and if you add information early other people – such as the person who created the bug – have an opportunity to clarify and contribute to the design or solution.

As a result of our sprint, we’re now focusing on how we can provide the best user experience for automating the process of building code into installable packages that will be updated on peoples machines the next day. In particular, we want to enable easy setup of daily builds for projects, allowing people who like to live on the edge and contribute QA time to their favourite open-source projects (building on the excellent work of bzr-builder).

To encourage involvement in this process, I’m trying a combination of relevant email lists for discussion, phone calls where helpful, and a wiki page that I try to keep up-to-date with the current status of those discussions. The aim being that anyone can read the wiki page and, in addition to seeing the current UI mockups, can see all the significant questions that have been brought up already. We’ll see how it goes…


Read more
beuno

After a year and a half in the User Experience team at Canonical, I’ve decided to move to the Ubuntu One team. It’s been an amazing experience to be part of that team but I’ve been missing doing development on a regular basis a lot lately, so I’ve decided to move into a role where I can get my hands dirty more often.

I will start by taking on anything on the web interface together with an amazing team, we will deliver a great experience and a higher level of polish for Lucid. There are some exciting new features coming to Ubuntu One, so it’s a great time to be part of the team, especially with John Lenton and Elliot Murphy as managers.

This does mean I will be moving away from the work I’ve been doing on Launchpad which makes me sad, it’s a fantastic and ambitious project filled with the smartest and most passionate engineers I’ve known.

If in the next few months you don’t start feeling like life is getting better for you on the Ubuntu One web UI, please come and find me and point me and hold me up to my promise of wonderful webby things.

Read more
bigjools

Success in Wellington

One of the  things that Launchpad is working on is the daily builds project, where we take a source branch, a recipe and turn it into a source package that can be built.

It turns out that this is quite hard because you need a secure environment to run the Bazaar recipe builder in.  Fortunately we already have the Launchpad Build Farm!  So, on January 11th the Soyuz and Codehosting teams, plus Launchpad Strategist Jono Lange and community contributor William Grant all met at the West Plaza Hotel in Wellington, New Zealand for a week-long coding sprint with the goal of getting a recipe build job through the build farm before the week was out.

The team hard at work

The amount of work was pretty sizeable, but we’d already done quite a lot of preparatory work before leaving so that non-Soyuz developers could get involved from day one.

We split the task into a few areas:

  • Writing the code that runs on the build slave itself
  • Job dispatching
  • Job collection
  • Job candidate selection
  • Creating a generalised build infrastructure to make it easy to plug in new job types

The team split into coding pairs that mostly lasted the week and there were no bloodied noses!  We had a strict rule that no pair could contain two people from the same Launchpad team, so that we could spread the knowledge around better.  This worked out really well.

The local coffee shop certainly had plenty of custom that week!  But by the end of it, on Friday afternoon at about 5:45pm, we finally got a recipe build job to run through a local Launchpad instance on William’s laptop and eventually turned into a binary package.  Success!

We’ll be building on this work in the next couple of months so that it has a UI that will allow a user to click on a branch and get it built and uploaded to their PPA.  It’s all very cool!

Finally, huge thanks to everyone involved, including the hotel.  It was the best wifi/internet anyone had ever had at any hotel, ever.

Bjorn, William and Michael

The team celebrates after a long week


Read more
pitti

These days I often use launchpadlib in my projects for scripting access/modifications in Launchpad. While launchpadlib has quite a good API documentation, this only covers the method calls, not the attributes or collections. So it often takes some poking and trying until you figure out how to access/change things.

I found myself typing the same things over and over, so I finally wrote a little script called lpshell:

#!/usr/bin/python -i
import code, os, sys
from launchpadlib.launchpad import Launchpad, STAGING_SERVICE_ROOT, EDGE_SERVICE_ROOT
lp = Launchpad.login_with('test', STAGING_SERVICE_ROOT)

This logs into Launchpad and gives you an interactive Python shell with an “lp” object:

$ lpshell
>>> lp.bugs[439482].duplicate_of

Update: I committed this to ubuntu-dev-tools now, renamed to lp-shell for consistency with the other lp-* commands.

Read more
Ian Clatworthy

One of the primary reasons why Bazaar exists is that Canonical wants to make it as easy as possible for more people to contribute to FOSS (Free and Open Source Software) projects. After many years of development, the pieces of the puzzle are really falling into place nicely. See the tutorial I put together last week to see just how easy it can be.


Read more
beuno

All projects in Canonical have a strong focus on testing. From all of them, I think Bazaar ranks the highest on obsesiveness on testing. As a drive-by contributor, it always felt like a very high entry barrier, and deterred me from getting into complicated changes. It was only after I bit the bullet and got into more complicated changes (in Launchpad, actually) that I understood that tests where my best friends ever. It’s a safety net against myself, and actually lowers the barrier, because I don’t need to know about the rest of the code base to make a change, tests will tell me if I break something (seemingly) unrelated.

On the more extreme side, there is test driven development (TDD). You write the tests first, watch them fail, and then start producing the code that will get them to pass. Having co-authored bzr-upload with the TDD-obsessed bzr developer, Vincent Ladeuil, I thought that if I was going to add a new feature, I may just as well try it (again).

It rocked.

I set up the test, my carrot, and the task went from “start poking around code” to “fix this problem”. With the test written, it became very clear what parts of the code I needed to change, and how the feature had to work.

The results?  in one hour, I implemented a feature that lets you ignore specific files on upload. With tests.

Read more
Tim Penhey (thumper)

Don't wait for perfection

Way back in July I was thinking of writing a post about the new branch listings in Launchpad. I was working on making branch listings for distributions and distroseries work, for example Package branches for Ubuntu and Packages branches for Ubuntu Lucid. But the code wasn't entirely optimised. Then as things happen, the optimisation got pushed back... and back. And finally when I did get the optimisation in, I didn't feel it was worthy of talking about.

I guess the thing to remember is: don't wait for perfection. Sure it wasn't perfect, but if more people were accessing the pages, the optimisation may have happened sooner.

One thing going on at the moment is more integration of the lazr-js widgets. The main merge proposal page now has in in-page multi-line editor for the commit message. Sure, it needs tweaking, but the main functionality is there. More ajaxy goodness is finding its way into Launchpad.

One of the things that I'm thinking about right now is splitting the concepts of code reviews and merge proposals. At the moment we almost use the term interchangeably, which does cause some confusion. I'd like to have the merge proposal reflect the meta-data and information around the intent to have work from one branch be landed or merged into another branch (normally the trunk branch), and the code review the conversation that goes on around the merge proposal. Merge proposals may have an associated code review, but right now, a code review must be associated with a merge proposal.

Associated with this, I'd like to extract some state information. Currently merge proposals have only one status, which really reflects two things. I'd like to break this out into two: review status; and merge status. Review status would be one of: work in progress; needs review; approved; rejected; superseded; and maybe withdrawn. Merge status would be one of: proposed; merged; queued; and merge failed. Queued relates to the merge queues which are currently partially implemented in the Launchpad codebase, and merge failed is the state that a proposal would be set to when a landing robot like PQM or Tarmac attempt to land the branch but it fails due to either merge conflicts or test failures.

My goal for the next six months it to write more often, talk about ideas more, and not wait for perfection.

Read more
pitti

I often do upstream releases of my upstream projects that I do on Launchpad, mostly for Apport and jockey. But doing this has been quite tedious until now: You have to go to the project page, pick the series (usually “trunk”), create a new release, create a new milestone along the way, then go to “add download file”, and upload your .tar.gz and .tar.gz.asc.

Because this is rather inconvenient, I don’t do as many upstream releases as I should. But thanks to our tireless launchpadlib developers it is now possible to automate all that, so I wrote a new script lp-project-upload which does all that in a simple command:

  $ lp-project-upload apport 1.8.2 apport-1.8.2.tar.gz
  Release 1.8.2 could not be found for project. Create it? (Y/n) y
 

The script is based on Brad Crittenden’s recipe for uploading project files, and I added the creation of milestones and releases.

The script is contained in current Karmic’s ubuntu-dev-tools package now. Enjoy, and of course feel free to extend it for changelogs, release notes, etc.

Read more