Sinzui

I have been fixing Launchpad page timeouts. This is traditionally solved by optimising queries, but in the case of timeouts related to milestones, the problem in in the Python code. The primary reason milestones are slow is that bugs are shown or summarised, which requires repetitive permission checks. The secondary reason is the number of bugs and blueprints that are shown so that the release manager can make informed decisions.

I choose two approaches to solve the two problems. In the case of bugs and bug tasks, I applied a faster permission checker on they after first verifying that the user had view permissions for all of them. For listing large chunks of content, I used the new memcached tales directives written by Stuart. They are easy to use, but some fore-though is needed because you must understand how the content will vary when viewed by different users.

In my first pass, I used <tal:cache content="cache:public, 1 hour"/> to wrap content that did not contain private data so that all users saw the same chunk. I used <tal:cache content="cache:private, 1 hour"/> to wrap bugs. This gives each user a a cached view and all anonymous users a shared cached view. After a few test failures, I realised I also needed to use the private rule for chunks that may contain links to modify objects; milestone listing often contain links that encourage the release manager to provide information.

Browser tests may also require you to uses MemcacheLayer.purge() to verify the changes users will see when cache expires. While you can clear the memcached when content changes, there is API (yet) to clear all page caches that involve the modified object.

With a few deft lines of code, I was able to speed up milestone and series pages. I had also made projects and distro pages faster since they share portlets with series. I decided to extend the scope of my branch to cache the public content in all the portlets used by distros, projects, and project groups. You may need to wait an hour to see the latest bug reported in the Ubuntu main page, or see a bug appear on the milestone page, but the pages will load faster, which is better for most users.

Over the past few months, it occurred to me that by a confluence of Launchpad responsibilities, I am the God-Emperor of Launchpad Registry Admins. I never intended to take this role. I certainly did not covet it. I just realised that there were a lot of data issues in Launchpad that I personally had the power to fix.

One, Launchpad engineers are members of the Registry Admin team because we are often requested to update projects that do have a Launchpad maintainer (those projects owned by Registry Admins). We are thus, the itinerant maintainers of more than 1500 projects. Projects that were missing license information, missing source code, and missing upstream bug tracking information. These are projects that need someone to adopt, keep the data current, and ensure it can be used by any Launchpad community.

Two, Most Launchpad questions are about project and user management, which is the domain of the Launchpad registry app, and I am the only answer contact. When you want a registry admin project updated, or you want to adopt it, I am the person who helps you. I work with all project and team issues. So while all Launchpad engineers are Registry Admins, I am the person who uses the responsibility most often.

Three, I review every registered project, checking that it is legitimate and has proper licenses. Many new projects are gifted to the Registry Admin team, and I provide the missing information. I review 25 or more registered projects every day. I reviewed the 4000+ backlog of projects last year.

Four, The project review form is insane, and it would be easier for me to see the state of all projects if all projects have licenses…so I set the license information the Registry Admin owned projects. And since I was looking at the project page, I updated the home page link and linked the project to an Ubuntu package when I could. I fixed about 1000 projects.