Current documentation for “Launchpad itself”

Bugs, People and Roles for Launchpad itself

Bugzilla has default assignees. Malone, for distribution packages, uses the package maintainers and explicit assignees for similar purposes. There are issues with this model that need clarifying, potentially leading to improvements in the Malone model.

Enhanced Production Rollout Process for Launchpad itself

Please enhance the production rollout process to further articulate the anatomy of a release based upon the requirements provided by kiko via Joey. This spec does not have a wiki entry.

Launchpad Rollout Procedures for Launchpad itself

With more and more infrastructure relying on Launchpad and the database being available, we need to define policies and procedures for rollouts so required downtime does not affect other peoples schedules. Some guidelines as to what people consider acceptible downtime will also need to be determined.

Roadmap to Launchpad dogfooding for Launchpad itself

What is required to get launchpad developers using the branch facilities within launchpad.

Terminology for active and published submissions for Launchpad itself

* Overview: 'published' and 'active' field names (on POSubmission table) are hardly understandable. Through one review, it occurred to me that we could use simple names like 'imported' for published (with obvious conflict between imported-by-a-translator-through-LP), and 'current' for active. Kiko seems to like...

SuperMirror Overview for Launchpad itself

This specification covers a generalized explanation of the relationship between the supermirror, launchpad, the bzr client and other related features

Essential documentation for Support for Launchpad itself

Essential documentation for support features that are in 1.0. Think 5 pages, not 50 pages.

Resolving licensing issues for translations for Launchpad itself

With our translations coming from sources with different licensing conditions, we are running into problems of legally sharing and reusing them. And when we add into mix translation submitted via Rosetta as well, we end up with a licensing nightmare. What are options in resolving this? What can we do short term? A...

Launchpad login service for Launchpad itself

Improve security by establishing a central "Launchpad Login Service" where people can register and sign in.

Build UI improvements for Launchpad itself

Improving the Launchpad build UI to provide amongst other features to be specified, a 'global view of the build queue'.

Granular Launchpad Permissions for Launchpad itself

We need to collect use cases for where we want more specific and granular launchpad permissions, enabling the infrastructure team to design and implement the system correctly.

Essential documentation for Malone for Launchpad itself

Essential documentation covering the features in Malone for 1.0. Think 5-pages more than 50 pages.

Mass Bug Editing for Launchpad itself

This blueprint outlines a new feature to support mass editing of bugs in Launchpad. The feature will extend the user interface so that users can change collections of bugs at the same time, with ease. To make the implementation more manageable, we'll tackle it over a number of phases. Each phase will bring increm...

Code review within launchpad for Launchpad itself

There should be a way to hold conversations about code review within Launchpad. For example when a branch is linked to a bug, we'd like to click from there to a review of the branch. The review should have a series of dated text comments by various people, plus an overall positive/negative result for each one. It...

Launchpad Reviewer's Guide for Launchpad itself

This Reviewer's Guide to Launchpad introduces you to a few of the highlights of the Launchpad experience.

Symmetry between Product and ProductSeries for Launchpad itself

Under some circumstances, we should explore the symmetry between a specific product series and the product itself. The same is true in the distribution world. This spec outlines the ideas and opportunities that this symmetry presents.

Creating Branches On Supermirror for Launchpad itself

This specification describes support in Bazaar and Bazaar-ng for creating branches in the supermirror.

Rosetta Administration for Launchpad itself

With a system as big as Rosetta, we need a way to do some admin stuff easily. This document explains a set of actions that should be executed as a Rosetta admin.

Rosetta Use Cases for Launchpad itself

This document explains the Rosetta Use Cases we are aware of based on our own experience and feedback from the community.

Rosetta Workflow for Launchpad itself

This is an overview of how people use Rosetta, with links to relevant detailed specifications. Implementation plans belong in those detailed specifications.

Translation Workflow for Launchpad itself

The translation process is designed to allow efficient sharing of translations between people working on upstream packages and those working on various distributions. People can see translations used in other places, and maybe add a translation of their own. A distinction is made between normal contributors and edit...

Authentication Overview for Launchpad itself

This spec should just provide an overview of current and planned Launchpad authentication features. It will link to our other auth specs, link to other auth systems we may want to look at/use like OpenID, and describe a roadmap for Launchpad's authentication.

Improving import queue management for Launchpad itself

The volume of translation uploads has grown too large for a small team of humans to manage, resulting in a long queue of translation import requests. Many of these must be reviewed by hand. Here we go through several improvements to how the application supports this process, with the specific goal of speeding up t...

Launchpad Email Addresses for Launchpad itself

What email addresses are to be used by the various components of launchpad to send email from.

Roadmap for the web UI for Launchpad itself

This spec outlines the dependencies to get the web UI that we want.

Bug page for Launchpad itself

This a functional specification, not an iteration specification. It describes how all the elements on a bug report page should be laid out, so that they work together consistently and harmoniously. It should be updated as bug-related features are added to or removed from Launchpad.

Soyuz features required for Ubuntu release management support for Launchpad itself

This specification will document the current Ubuntu release procedure and the Soyuz features and tools related. Additionally, it will help to identify missing features to accomplish all the Ubuntu requirements.

Blog Integration Overview for Launchpad itself

Overview of plans for the integration of blogosphere awareness into Launchpad. This describes the phases of the planned implementation, there are separate specs that give the details of each phase itself.

Blueprint Documentation for Launchpad itself

This is the root of the documentation for Blueprint. Start here to learn how to use Launchpad for feature tracking, release planning and development progress reporting.

The Packaging Table for Launchpad itself

The Packaging table is the only solid link between a sourcepackage and a product. This is unfortunate as there is no perfect way of populating this table as we have no guaranteed way of determining this linkage from available data. ie. a source package cannot tell us what Products it contains, and product informatio...

Launchpad specification tracker for Launchpad itself

You can use Launchpad to track specifications. The actual specifications live elsewhere, on wikis on the internet. The metadata for specs is tracked inside Launchpad.

UI for licensing issues for Launchpad itself

Design user interface bits and text for licensing issues.

a series of improvements on translation workflow for Launchpad itself

This a "Goal Specification" for different improvement, signed as dependencies

Development plan for the first half of 2007 for Launchpad itself

Strategic planning document for the first half of 2007. Starting from a few high-level goals and detailing them into objectives and actions. Gotta love my pointy hair!

CodeImport phase two for Launchpad itself

Phase two is the stage where we replace buildbot with the new server side scripts, and clean up the product series.

CodeImport security vs. complexity trade-off for Launchpad itself

Summary of security trade-offs underlying the design of the Code Import Roadmap.

Document and discuss Soyuz code architecture for Launchpad itself

Document and discuss Soyuz code architecture. This includes reviewing and refining existing documentation if it is out of date. Ideally, this would create an overview that is suitable for newcomers to Soyuz.

Document and discuss the Soyuz package life cycle for Launchpad itself

Document and discuss the Soyuz package life cycle.

Hardware Database Phase 1 for Launchpad itself

A placeholder spec dependent on all Hardware Database specs.

Hardware Database Phase 2 for Launchpad itself

Placeholder spec for attaching dependancies for the second phase of the Hardware Database implementation.

Hardware Database Phase 3 for Launchpad itself

Phase 3 of the Hardware Database.

Hardware Database Submission Format for Launchpad itself

The initial file format that the Hardware Database Client will upload files to Launchpad in.

Linux Introduction and tutorial magazine for Launchpad itself

This is the Linux Introduction magazine for newbies...

New OOPS format for Launchpad itself

This specification describes the format of the new OOPS logs. This new format solves the issue of taking too much disk space with error logs and is easily extensible to cope with future changes.

Document and discuss Soyuz production set up for Launchpad itself

Document and discuss Soyuz production set up. Include: host machines, procedures to follow, scripts to run, cronjobs etc.

How things could work some time in the future for Launchpad itself

A thought exercise on how things could work.