launchpad development|
Size: 13559
Comment:
|
← Revision 61 as of 2010-01-05 07:14:36 ⇥
Size: 10775
Comment: Highlight whether or not stories are on the roadmap
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| == Patch forwarding == * As a non-core developer using Launchpad and Bazaar,<<BR>> I want to give my fix to upstream in a way they can merge it using their tools,<<BR>> 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 * As an Ubuntu developer,<<BR>> I want to see which patches in my package that need to be sent upstream,<<BR>> 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 * As an Ubuntu developer,<<BR>> I want to see which patches that have been sent upstream have been merged,<<BR>> 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. * As a drive-by upstream contributor (John)<<BR>> I want to point upstream to my fix in Launchpad<<BR>> So that my fix can be easily merged upstream. * As a drive-by upsteam contributor (John)<<BR>> I want the upstream bug tracker to be notified when my fix is ready in LP<<BR>> So they can merge my fix * As a developer<<BR>> I want bug followers to be notified when my linked branch is ready for review<<BR>> So that they can try out and review my fix == Automatic upstream releases discovery == * As an Ubuntu user who has found their software is too old<<BR>> I want to find newer versions of the package (in PPAs, backports, etc.) So that I can get past the bug I'm encountering. * As an Ubuntu packager (Kara)<<BR>> I want to be notified when upstream makes available a new release<<BR>> So that I can package it. * As an ubuntu package maintainer maintaining multiple packages<<BR>> I want launchpad to tell me about new releases<<BR>> so that I know when to package these new releases * As the developer of an upstream project<<BR>> I want the latest releases of my project automatically linked to the Ubuntu package<<BR>> so I can be sure that they'll get into Ubuntu without me having to push for it == Translations forwarding == * As an upstream developer (John/Jeremy) <<BR>> I want to see translations made for the Ubuntu package of my software shared with my project translation effort <<BR>> So that I don't feel the translation effort made on the distro is not benefiting my project. * As an Ubuntu developer,<<BR>> I want to see translations made for an upstream package automatically shared with the Ubuntu package's translation effort,<<BR>> so that people don't waste time translatating strings for a package that have already been translated upstream. * As a developer on an upstream project<<BR>> I want my project to be translated into as many languages as possible<<BR>> so that I will get more users * As a developer on an upstream project<<BR>> I want to get the translations of my project that are on Launchpad into my project<<BR>> so that I don't have to organize the work myself == Translations Import == * As a non-English speaker using Ubuntu<<BR>> I want the software that I use to be translated into my language<<BR>> so that I can actually use it! * As an Ubuntu translator<<BR>> I want the translation data for any upstream project to be available in Launchpad<<BR>> so that I can translate the upstream into my language and get it into Ubuntu * As an Ubuntu translator<<BR>> I want to be able to use the translation already done on Ubuntu or an upstream to be available whenever I translate something new<<BR>> so that I avoid duplicating work and thus wasting my time == Notifications control == * As a person who gets too much mail<<BR>> I want to see all the reasons (or channels/causes/sources) why Launchpad is sending me email<<BR>> So that I can turn some off. * As John the coder<<BR>> I want to get mail when anything changes<<BR>> So that I can search/read it offline. * An an Ubuntu user<<BR>> I want to be told only when a bug is believed to be fixed<<BR>> 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") * As an irritable Ubuntu user<<BR>> I want to stop _all_ mail LP<<BR>> So that I don't feel spammed. == Bug forwarding == * An a Ubuntu developer<<BR>> I want to make an external upstream aware of a triaged bug in Ubuntu<<BR>> So that they can fix it |
## page was renamed from VersionFourDotO/Themes <<TableOfContents(1)>> 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. Not all the stories that we came up with are here. There are also many stories that we aren't going to work on right now that we hope to [[/LaterStories|work on later]]. Other stories that we came up with were duplicates of the ones here. We've kept them for reference at [[/DuplicateStories]]. <<Anchor(bugs-off-ubuntu)>> = Getting bugs "off" Ubuntu = <<Anchor(story-1)>> == Story 1 == As an Ubuntu developer<<BR>> I want to see only valid, well-written bugs that actually affect Ubuntu when I am doing Ubuntu development<<BR>> so that I can make quick, informed decisions about what to work on. <<Anchor(story-1.1)>> === Story 1.1 === ||<#ffa0a0>XXX - Not on RoadMap|| As an Ubuntu QA engineer<<BR>> I want to report a bug already reported in Ubuntu to the upstream bug tracker using a single button<<BR>> 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" <<Anchor(story-1.2)>> === Story 1.2 === ||<#ffffa0>FIXME - not directly on RoadMap, but kind of "supporting technologies" track.|| * As an Ubuntu QA engineer<<BR>> I want just-in-time easy registration of an upstream project and bug tracker, as part of my bug-forwarding workflow<<BR>> So that I can start forwarding bugs right away without breaking my workflow. <<Anchor(story-1.3)>> === Story 1.3 === ||<#ffa0a0>XXX - Not on RoadMap|| |
| Line 137: | Line 56: |
| I want to be told when a bug in my software in Ubuntu is determined to be an upstream bug<<BR>> |
I want to be told when a bug in my software in Ubuntu is determined to be an upstream bug<<BR>> |
| Line 141: | Line 59: |
| == Upstream registration == * As an Ubuntu QA engineer<<BR>> I want to register very quickly an upstream project and bug tracker<<BR>> So that I can forward bugs to them == Integrated bug reporting / Bug imports == |
<<Anchor(story-1.4)>> === Story 1.4 === ||<#ffa0a0>XXX - Not on RoadMap|| |
| Line 150: | Line 65: |
| I want when reporting a bug to see if the problem is known in Ubuntu or upstream <<BR>> So that I don't file a duplicate and maybe find a work-around. * As an Ubuntu user,<<BR>> I want to have one place to find out whether the problem I'm experiencing has already been reported whether that's upstream or in Ubuntu,<<BR>> so that I can follow the progress of the bug fix wherever that may happen. * As an Ubuntu QA user<<BR>> I want to search the external upstream bug tracker through Launchpad<<BR>> So that I can if an issue is already known/fixed * As an Ubuntu QA contact,<<BR>> |
I want when reporting a bug in Ubuntu to see if the problem is known upstream<<BR>> So that I can follow the progress of the bug fix wherever that may happen, and maybe learn about a workaround. <<Anchor(story-1.5)>> === Story 1.5 === ||<#ffa0a0>XXX - Not on RoadMap|| * As an Ubuntu QA engineer,<<BR>> |
| Line 167: | Line 77: |
== Debian PPAs == * As a Gnome-Do developer,<<BR>> I want to provide Debian packages in our project PPA <<BR>> So that Debian users can get the latest releases '''Notes:''' Bug #188564 * As an Ubuntu developer who also maintain the Debian package,<<BR>> I want to upload my package to Launchpad and have it published both for Ubuntu and Debian<<BR>> So that it's easier to keep Ubuntu and Debian version of the package in sync. '''Notes:''' Bug #188564 == User-driven imports == * As an Ubuntu developer,<<BR>> I want an upstream branch available for all the packages in main<<BR>> So that I can easily have access to the source code. * As a Ubuntu developer who found that the upstream branch not available in Launchpad<<BR>> I want to quickly register a code import for it<<BR>> So that I can access the source code from Launchpad. '''Notes:''' Implies low-latency * As an Ubuntu fan,<<BR>> I want to quickly add upstream data for all packages that are missing it<<BR>> So that I can help the project although I'm not a coder (and earn karma and brag about it). * As the driver of an Ubuntu release<<BR>> I want to all packages in the release linked to upstream releases<<BR>> so that I can choose the best version to include in Ubuntu == User driven bug QA == * As an Ubuntu developer (John)<<BR>> I want to be distracted as little as possible by unconfirmed bugs and fixed bugs<<BR>> So that I can spend as much time as possible coding fixes. == Self-completing / self-sorting bug == * As an Ubuntu QA engineer<<BR>> I want the bug reports to complete itself<<BR>> So that most of the bug that I triage are complete. |
<<Anchor(story-1.6)>> === Story 1.6 === ||<#a0ffa0>Bug Q&A on RoadMap|| |
| Line 223: | Line 88: |
| * As an Ubuntu QA engineer,<<BR>> I want to know how many users are affected by a bug<<BR>> So that I can prioritise bugs more easily. * As a developer<<BR>> I want incomplete bugs to automatically go back to confirmed when the reporter provides the requested information<<BR>> So that I don't have to mark them confirmed myself. == Better code imports == * As Kara (the gcc maint in Ubuntu)<<BR>> I need to apply a mechanichal patch to 70 Gnome packages for a new gcc version<<BR>> So that I can prepare them for shipment in Ubuntu. == Building community == * As an Ubuntu user in Serbia<<BR>> I need to help with translations for tools I use <<BR>> So that I can improve my own experience * As John, the Ubuntu maintainer of Gwivver<<BR>> I need to coordinate UI changes in the current release<<BR>> So that address Ubuntu users' issues with this application * As the MySQL release manager <<BR>> I need to talk to the Ubuntu release manager<<BR>> So that we can coordinate our next release cycle * As the Ubuntu release manager<<BR>> I need to like to quickly distinguish people who are important to me<<BR>> So that focus on the right issues from incoming requests == Privacy for bug / branches == * As Bill, the OEM manager for Dell<<BR>> I want to help my external, secret translations team that I hired for our upcoming secret release create package translations <<BR>> So that I can ship our product in 20 languages * As Bill, the OEM manager for Dell<<BR>> I need to send our translations upstream from our previous release<<BR>> So that stop maintaining our translation and reduce costs * As as 3rd party contract developer for Dell<<BR>> I need to maintain my specific versions of upstream changes<<BR>> So that I can add them to Dell's product with current versions of packages * As Bill, the OEM manager for Dell<<BR>> I need to help my hired, secret coders for our upcoming secret release code<<BR>> customize and continue to follow trunk So that I can ship customized and up to date versions of our packages * As Bill, the OEM manager for Dell<<BR>> I need to send our patches upstream from our previous release<<BR>> So that stop maintaining our patches and reduce costs == Upstream / Package Links == * As someone who wants to interact with an upstream project<<BR>> I want to get everything about that project in Launchpad<<BR>> so that I don't have to learn new tools; and that I can take advantage of any network effects that Launchpad provides and that I don't have to context switch == Native source syncing == * As a package maintainer<<BR>> I want to sync the full history of Debian packages to Ubuntu<<BR>> so that the burden of maintaining these packages becomes lighter == Crack-of-the-day == |
= Package of the day Network = <<Anchor(story-2a)>> == Story 2 == ||<#a0ffa0>Daily builds on RoadMap|| * As an Ubuntu user who has found their software is too old<<BR>> I want to find newer versions of the package (in PPAs, backports, etc.)<<BR>> So that I can get past the bug I'm encountering. <<Anchor(story-2b)>> == Story 2' == ||<#a0ffa0>Daily builds on RoadMap|| |
| Line 298: | Line 106: |
| I want my trunk built regularly in Ubuntu,<<BR>> | I want the tip of my project readily available to Ubuntu desktop users,<<BR>> |
| Line 302: | Line 110: |
| * Having a build of tip always available is unrealistic. Having a daily (or regular) build is much more achievable and gets similar results. | |
| Line 305: | Line 114: |
| * As a bug triager,<<BR>> I want to have people be able to easily confirm the bug against latest trunk,<<BR>> 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. * As a fanatic user of Firefox,<<BR>> I want to always have the bleeding edge version installed,<<BR>> so that I have the latest features (and bragging rights). * As the developer of an upstream project<<BR>> I want the latest release of my project in ubuntu<<BR>> So I stop getting out-of-date bug reports from Ubuntu users == Package branch permission == * As an Ubuntu developer<<BR>> I want to upload to the official source package branch for a source package<<BR>> so that I can use Bazaar to do my work, rather than shitty Debian tools. == Package from branch == |
<<Anchor(story-2.1)>> === Story 2.1 === ||<#a0ffa0>Code import on RoadMap|| |
| Line 332: | Line 120: |
| I want to be able to take a branch of code and have it built into an Ubuntu package and distributed in a PPA,<<BR>> so that people interested in my package can test the tip code with minimal effort on my part and theirs. |
I want an upstream branch available for all the packages in main<<BR>> 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. Resources * [[https://lpstats.canonical.com/graphs/PackagesWithUpstreamBranchesMain/|Packages in main with upstream branches]] * [[https://lpstats.canonical.com/graphs/PackagesWithUpstreamBranchesTop100/|Top 100 packages with upstream branches]] * [[https://lpstats.canonical.com/graphs/FailingCodeImportsMetrics/|Failing code imports]] * [[https://lpstats.canonical.com/graphs/FailingCodeImportsMetricsPercentages/|Failing code import percentages]] <<Anchor(story-2.2)>> === Story 2.2 === ||<#ffffa0>FIXME - not directly on RoadMap, but kind of "supporting technologies" track.|| * As a Ubuntu developer who found that the upstream branch not available in Launchpad<<BR>> I want to quickly register a code import for it<<BR>> 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. <<Anchor(story-2.3)>> === Story 2.3 === ||<#a0ffa0>Daily builds on RoadMap|| |
| Line 342: | Line 154: |
| == Bugs in PPA == * As Bill the OEM manager,<<BR>> I want my QA team to test and give feedback as fast as possible for my distribution maitained in a PPA<<BR>> So that I produce higher quality release for my hardware. |
'''Notes:''' Doesn't take scheduling daily builds into account, but needs to in order to satisfy Story 2 and Story 2'. <<Anchor(story-2.4)>> === Story 2.4 === ||<#ffffa0>FIXME - what does this mean?|| * As an Ubuntu developer<<BR>> I want to upload a source package branch the way I upload a regular branch<<BR>> so I don't have to upload the whole thing every time I make a change <<Anchor(story-2.10)>> === Story 2.10 === ||<#ffa0a0>XXX - Not on RoadMap|| * As a tester of upstreams using Ubuntu<<BR>> I want my system to be updated daily with the latest code<<BR>> so I'm not wasting my efforts by testing old code <<Anchor(story-2.11)>> === Story 2.11 === ||<#a0ffa0>Daily builds on RoadMap|| * As a maintainer of a daily build<<BR>> I want my package to be rebuilt automatically when new versions are available<<BR>> so I don't have to trigger builds myself. = Archive Snapshot = <<Anchor(story-3.1)>> === Story 3.1 === ||<#ffa0a0>XXX - Not on RoadMap|| * As an Ubuntu developer<<BR>> I want to take a snapshot of the current state of the archive<<BR>> so I don't have to freeze development on that archive while I'm building an image. <<Anchor(story-3.2)>> === Story 3.2 === ||<#ffa0a0>XXX - Not on RoadMap|| * As an Ubuntu developer<<BR>> I want to tweak a single package in a snapshot<<BR>> so I can quickly fix bugs found in an image. = Translations = <<Anchor(story-4.1)>> === Story 4.1 === ||<#ffa0a0>XXX - Not on RoadMap|| * As an developer of an upstream project,<<BR>> I want to have translations of my project in Ubuntu to get into my project automatically,<<BR>> 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. <<Anchor(story-4.1.1)>> ==== Story 4.1.1 ==== ||<#ffa0a0>XXX - Not on RoadMap|| * As an upstream developer of an external project <<BR>> I want to see translations made for the Ubuntu package of my project submitted to my contribution tracker<<BR>> So that translation effort made on the distro benefits my project. <<Anchor(story-4.1.2)>> ==== Story 4.1.2 ==== ||<#ffa0a0>XXX - Not on RoadMap|| * As an upstream developer of a project in Launchpad <<BR>> I want to see translations made for the Ubuntu package of my software get to my project translations<<BR>> So that translation effort made on the distro benefits my project. <<Anchor(story-4.2)>> === Story 4.2 === ||<#a0ffa0>Translations on RoadMap|| * As an Ubuntu developer/translator,<<BR>> I want to have upstream translations automatically integrated into Ubuntu,<<BR>> so that people don't waste time translating strings for a package that have already been translated upstream. <<Anchor(story-4.2.0)>> ==== Story 4.2.0 ==== ||<#a0ffa0>Translations on RoadMap|| '''Depends on the Registry team''' * As an Ubuntu developer/translator,<<BR>> I want to be directed to set up an upstream project translations import,<<BR>> 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 <<Anchor(story-4.2.1)>> ==== Story 4.2.1 ==== ||<#a0ffa0>Translations on RoadMap|| * As an Ubuntu developer/translator,<<BR>> I want to see up-to-date upstream translations in Launchpad,<<BR>> so that it's easy to make use of them through global suggestions when translating Ubuntu. '''Main substory:''' * As an Ubuntu GNOME translator,<<BR>> I want Launchpad to import up-to-date upstream GNOME translations,<<BR>> so that it's easy for me to integrate latest GNOME translations in Ubuntu. '''For dummies:''' This means sucking information out of upstream branches, regenerating the POT files if the project is intltool-based. '''Technical steps:''' * Depends on generic build infrastructure * 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 <<Anchor(story-4.2.2)>> ==== Story 4.2.2 ==== ||<#a0ffa0>Translations on RoadMap|| * As an Ubuntu developer/translator,<<BR>> I want to see upstream project translations in Launchpad automatically used in Ubuntu using the general upstream import rules,<<BR>> so I don't have to manually activate them using global suggestions. <<Anchor(story-4.2.3)>> ==== Story 4.2.3 ==== ||<#ffa0a0>XXX - Not on RoadMap|| * As an Ubuntu translator,<<BR>> I want to translate only messages that are specific to Ubuntu package (not existing in upstream project templates),<<BR>> so I can deliver Ubuntu-specific translations faster. |
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.
Not all the stories that we came up with are here. There are also many stories that we aren't going to work on right now that we hope to work on later.
Other stories that we came up with were duplicates of the ones here. We've kept them for reference at /DuplicateStories.
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
XXX - Not on RoadMap |
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 upstreamNotes:
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
FIXME - not directly on RoadMap, but kind of "supporting technologies" track. |
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
XXX - Not on RoadMap |
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
XXX - Not on RoadMap |
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
XXX - Not on RoadMap |
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
Bug Q&A on RoadMap |
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.
Package of the day Network
Story 2
Daily builds on RoadMap |
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'
Daily builds on RoadMap |
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
Code import on RoadMap |
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.
Resources
Story 2.2
FIXME - not directly on RoadMap, but kind of "supporting technologies" track. |
- 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
Daily builds on RoadMap |
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
FIXME - what does this mean? |
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
XXX - Not on RoadMap |
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
Daily builds on RoadMap |
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.
Archive Snapshot
Story 3.1
XXX - Not on RoadMap |
As an Ubuntu 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.
Story 3.2
XXX - Not on RoadMap |
As an Ubuntu developer
I want to tweak a single package in a snapshot
so I can quickly fix bugs found in an image.
Translations
Story 4.1
XXX - Not on RoadMap |
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
XXX - Not on RoadMap |
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
XXX - Not on RoadMap |
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
Translations on RoadMap |
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
Translations on RoadMap |
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
Translations on RoadMap |
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.
For dummies:
This means sucking information out of upstream branches, regenerating the POT files if the project is intltool-based.
Technical steps:
- Depends on generic build infrastructure
- 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
Translations on RoadMap |
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
XXX - Not on RoadMap |
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.
