Differences between revisions 49 and 50

Contents

In Scope Stories
Package of the day Network
Archive Snapshot
Translations
Later Stories

These are the high-level UserStories that we'll be working on for the next major cycle of Launchpad development.

The stories are grouped into major "themes", and have numbers that match these themes.

In Scope Stories

Getting bugs "off" Ubuntu

Story 1

As an Ubuntu developer
I want to see only valid, well-written bugs that actually affect Ubuntu when I am doing Ubuntu development
so that I can make quick, informed decisions about what to work on.

Story 1.1

As an Ubuntu QA engineer
I want to report a bug already reported in Ubuntu to the upstream bug tracker using a single button
So that the bug can be fixed by upstream
Notes:
- Single button to forward bugs upstream. Anything more takes too much time & mental energy.
- Credentials stored in Launchpad so the bug looks like it came from me.
- Don't want to irritate the upstream, want to help them.
- "Be a good citizen"

Story 1.2

As an Ubuntu QA engineer
I want just-in-time easy registration of an upstream project and bug tracker, as part of my bug-forwarding workflow
So that I can start forwarding bugs right away without breaking my workflow.

Story 1.3

As an non-LP hosted upstream developer
I want to be told when a bug in my software in Ubuntu is determined to be an upstream bug
So that I can investigate it.

Story 1.4

As a Ubuntu user
I want when reporting a bug in Ubuntu to see if the problem is known upstream
So that I can follow the progress of the bug fix wherever that may happen, and maybe learn about a workaround.

Story 1.5

As an Ubuntu QA engineer,
I want to have all the bug reports from an upstream project in Launchpad
so that I can easily relate bugs reported against Ubuntu packages to upstream bug reports.

Story 1.6

As an Ubuntu QA engineer
I want users viewing an untriaged bug page to be prompted for a question helping the bug report become complete
So that I can be more effective in my triaging effort.

Stories below this line are not immediate priorities and are included for reference.

Story 1.7

XXX flacoste duplicate of 1.1
An a Ubuntu developer
I want to make an external upstream aware of a triaged bug in Ubuntu
So that we don't have to deal with it anymore.
Notes: Benefit isn't that realistic here.

Story 1.8

XXX flacoste Redundant with 1.
- As an Ubuntu developer (John)
  I want to spend as little time as possible processing bugs (confirming and triaging)
  So that I can spend as much time as possible coding fixes.
  - Notes: Launchpad could ask questions and/or use "affects me too" information to suggest triages and even auto-triage. IOW, Launchpad could do more to support crowdsourcing technically.

Story 1.9

XXX - jml - not that valuable in itself, but probably quite cheap to do after doing the inline project registration stuff required for the more critical stories. Also, LP would feel oddly incomplete without it.

As an Ubuntu fan,
I want to quickly add upstream data for packages that are missing it
So that I can help the project although I'm not a coder (and earn karma and brag about it).

Story 1.10

XXX - flacoste Too small to be on this list. JFDI.

As an Ubuntu QA engineer,
I want to know how many users are affected by a bug
So that I can prioritise bugs more easily.

Story 1.11

XXX - flacoste Better triage service, less than upstream.

As a developer
I want incomplete bugs to automatically go back to confirmed when the reporter provides the requested information
So that I don't have to mark them confirmed myself.

Story 1.12

XXX - jml Contingent to package of the day "network".

As an Ubuntu QA engineer,
I want to have people be able to easily confirm the bug against latest trunk,
so that I know whether the bug exists upstream.
- Notes:
  - This helps bug triagers to decide whether the bug is in Ubuntu, or should be sent upstream.
  - It's important that it's easy for the tester to test the latest version, without messing up his system.

Package of the day Network

Story 2

As an Ubuntu user who has found their software is too old
I want to find newer versions of the package (in PPAs, backports, etc.)
So that I can get past the bug I'm encountering.

Story 2'

As an upstream developer,
I want the tip of my project readily available to Ubuntu desktop users,
so that I know that it builds and testers can get to it easily,
- Notes:
  - Having a build of tip always available is unrealistic. Having a daily (or regular) build is much more achievable and gets similar results.
  - This gives the upstream a bigger testing ground. Ubuntu is a great means of getting their work to more people.

Story 2.1

As an Ubuntu developer,
I want an upstream branch available for all the packages in main
So that I can easily see the source code, for example to see if a bug has been fixed, or to see the delta between my package and recent upstream.

Story 2.2

As a Ubuntu developer who found that the upstream branch not available in
Launchpad
I want to quickly register a code import for it
So that I can work with the source code from Launchpad right away, and so I (or someone else) can rebase the corresponding source package branch to use Launchpad.
- Notes: Low latency is key here.

Story 2.3

As an Ubuntu developer,
I want to be able to build my source package branch into an Ubuntu package,
so that it takes less of my time and effort to get the software that interests me into Ubuntu.
- Notes: Doesn't take scheduling daily builds into account, but needs to in order to satisfy Story 2 and Story 2'.

Story 2.4

As an Ubuntu developer
I want to upload a source package branch the way I upload a regular branch
so I don't have to upload the whole thing every time I make a change

Story 2.10

As a tester of upstreams using Ubuntu
I want my system to be updated daily with the latest code
so I'm not wasting my efforts by testing old code

Story 2.11

As a maintainer of a daily build
I want my package to be rebuilt automatically when new versions are available
so I don't have to trigger builds myself.

Stories below this line are not immediate priorities and are included for reference.

Story 2.5

XXX - flacoste - Not related to package of the day (based on imports, not releases)
As an Ubuntu packager (Kara), possibly maintaining multiple packages,
I want to be notified when upstream makes available a new release
So that I can package it.

Story 2.6

XXX - flacoste - flipside of Story 2.5.
As the developer of an upstream project
I want the latest releases of my project automatically linked to the Ubuntu package
so I can be sure that they'll get into Ubuntu without me having to push for it

Story 2.7

XXX - duplicate of Story 2. - jml

As a fanatic user of Firefox,
I want to always have the bleeding edge version installed,
so that I have the latest features (and bragging rights).
- Notes:
  - Probably requires some sort of linking from products to PPAs.
  - Worth considering whether other types of package archives are appropriate. e.g. "project package archives" as distinct from "personal package archives".
  - We should also consider dealing with the lack of '~' in PPA urls.

Story 2.8

XXX - another Story 2.5 duplicate - flacoste

As the developer of an upstream project
I want the latest release of my project in ubuntu
So I stop getting out-of-date bug reports from Ubuntu users

Story 2.9

XXX - dupe of story 2.3 - jml

As an Ubuntu developer,
I want to be able to take a branch of code and have it built into an Ubuntu package and distributed in a PPA,
so that people interested in my package can test the tip code with minimal effort on my part and theirs.

Archive Snapshot

Story 3.1

As an OEM services developer
I want to take a snapshot of the current state of the archive
so I don't have to freeze development on that archive while I'm building an image.
- Notes: Also applies to Ubuntu developers.

Story 3.2

As an OEM services developer
I want to tweak a single package in a snapshot
so I can quickly fix bugs found in an image.
- Notes: Also applies to Ubuntu developers.

Translations

Story 4.1

As an developer of an upstream project,
I want to have translations of my project in Ubuntu to get into my project automatically,
so I don't have to manually merge them over and over again and my project gets the benefit of the work done in Ubuntu.

Story 4.1.1

As an upstream developer of an external project
I want to see translations made for the Ubuntu package of my project submitted to my contribution tracker
So that translation effort made on the distro benefits my project.

Story 4.1.2

As an upstream developer of a project in Launchpad
I want to see translations made for the Ubuntu package of my software get to my project translations
So that translation effort made on the distro benefits my project.

Story 4.2

As an Ubuntu developer/translator,
I want to have upstream translations automatically integrated into Ubuntu,
so that people don't waste time translating strings for a package that have already been translated upstream.

Story 4.2.0

Depends on the Registry team

As an Ubuntu developer/translator,
I want to be directed to set up an upstream project translations import,
so that I can use upstream translations in Ubuntu.

Requirements:

get upstream project registered
package <-> upstream link
get code imported
indicate that translations should be imported, and direct people to the process from translations pages

Story 4.2.1

Depends on the Soyuz team (for secure env set-up)

As an Ubuntu developer/translator,
I want to see up-to-date upstream translations in Launchpad,
so that it's easy to make use of them through global suggestions when translating Ubuntu.

Main substory:

As an Ubuntu GNOME translator,
I want Launchpad to import up-to-date upstream GNOME translations,
so that it's easy for me to integrate latest GNOME translations in Ubuntu.

Technical steps:

Regenerate POT files for GNOME
- Figuring out that project is intltool-based (est. cost: 2)
- Establish a secure environment to run the process in (UNKNOWN QUANTITY)
- Full branch checkout (1)
- Find all relevant translation templates (1)
- Regenerate all POT files (2)
- Insert POT into import queue together with PO files (UNKNOWN)
- Side-optimization: extend super-fast-imports to deal with POT files as well so we don't repeatedly re-import them with every commit

Story 4.2.2

As an Ubuntu developer/translator,
I want to see upstream project translations in Launchpad automatically used in Ubuntu using the general upstream import rules,
so I don't have to manually activate them using global suggestions.

Story 4.2.3

As an Ubuntu translator,
I want to translate only messages that are specific to Ubuntu package (not existing in upstream project templates),
so I can deliver Ubuntu-specific translations faster.

Later Stories

Patch forwarding

Story A

As a non-core developer using Launchpad and Bazaar,
I want to give my fix to upstream in a way they can merge it using their tools,
so that we both can use our tools we're comfortable with when collaborating
- Notes:
  - do we need a story about submitting a patch contained in a source package?
  - point the upstream developers either to a URL they can merge from directly, or a page containing the diff, information about the patch, and instructions about how to merge the fix using their tools. E.g., if we have an import of a git branch, there should be instructions for how to merge the fix using git.
  - push notifications about fixes ready for review through bug syncing

Story B

As an Ubuntu developer,
I want to see which patches in my package that need to be sent upstream,
so that others can benefit from my work
- Notes:
  - Helps the Ubuntu developer to see what needs to be done to reduce the delta to upstream, and to see how he can contribute to the upstream project

Story C

As an Ubuntu developer,
I want to see which patches that have been sent upstream have been merged,
so that I can politely remind upstream to merge my work.
- Notes:
  - This may be used for the Ubuntu developer to make sure that his work actually gets merged, and is not forgotten about.
  - This will also make it possible for upstream, so see whether there are patches in Launchpad for them.

Story D

As a drive-by upstream contributor (John)
I want to point upstream to my fix in Launchpad
So that my fix can be easily merged upstream.

Story E

As a drive-by upsteam contributor (John)
I want the upstream bug tracker to be notified when my fix is ready in LP
So they can merge my fix

Story F

As a developer
I want bug followers to be notified when my linked branch is ready for review
So that they can try out and review my fix

Story J

An an Ubuntu user
I want to be told only when a bug is believed to be fixed
So that I can test the fix (without lots of "noise" mail)
- Notes: Needs to know how to test (eg. "in Karmic" or "in this PPA")

Story K

As a person who gets too much mail
I want to be able to selectively turn off some Launchpad mails
So that I can get less mail.

Story L

As an irritable Ubuntu user
I want to stop _all_ mail LP
So that I don't feel spammed.

Story M

As John the coder
I want to get mail when anything (in a product, in a distro, in a team, etc) changes
So that I can use my preferred client and search/read the data offline.

Story N

XXX - sabdfl has ruled as out of scope.

As someone who makes Ubuntu packages (whether distro or PPA),
I want to upload my package to Launchpad and have it published both for Ubuntu and Debian
So that it's easier for Debian to test my improvements (e.g., bug fixes that haven't been sent upstream yet)
- Notes: Bug #188564 ("Build also packages for Debian in PPA's")

Story O

As the driver of an Ubuntu release
I want to link all packages in the release to upstream releases
so that I can choose the best version to include in Ubuntu.

Story P

XXX - jml doesn't understand this.

As Kara (the gcc maint in Ubuntu)
I need to apply a mechanichal patch to 70 Gnome packages for a new gcc version
So that I can prepare them for shipment in Ubuntu.

Story R