Launchpad Upstream Improvements
Launchpad Entry: https://blueprints.edge.launchpad.net/ubuntu/+spec/community-lucid-launchpad-upstream-improvements
Created:
Contributors: jcastro, deryck, kfogel
Packages affected:
See also: SpecTemplate
Summary
Launchpad can be a much better tool for connecting upstreams to Ubuntu developers. This spec will outline one feature that we think will be a good first start.
Rationale
Upstreams frequently complain that it is difficult for them to find Ubuntu patches. patches.ubuntu.com is a diff between Ubuntu and Debian, so it's not really useful to some upstreams.
We want an upstream patch report that shows patches in packages and their age, so we can act on them. Bryce has a working prototype that he made for himself that would be a good first start: http://www2.bryceharrington.org:8080/X/Reports/patches.html
Use Cases
- Bryce has a bunch of bugs and needs to determine which ones are oldest so he can adjust his workflow. The report allows him to quickly go over the oldest bugs and triage them.
- Scotty has submitted a patch to an Ubuntu package that hasn't been getting any attention. From looking at the patch report, Till is able to determine that the patch is up to date and would be a low hanging fruit, encouraging him to look at it.
- Luke is an upstream and notices that 3 distros are carrying the same patch to fix a bug; he thens looks at all three patches to judge who fixes it best and perhaps takes that upstream or fixes it himself.
- James runs into a bug in Evolution and wants to fix it, before he starts hacking he looks at the patch report and finds that another distro is already carrying a patch that does that. James sucks it into Ubuntu, passes it along to Debian, and pushes it upstream.
- Sandy, an upstream, is sick of tracking individual bug trackers for every distro and chasing down maintainers looking for patches. He merely subscribes to the patch report for his package and is notified when any distribution lands a patch for his package.
- Mathiue is a developer but doesn't know where to begin, he picks a pet project and sorts the patches by triage state and then begins reviewing them and submitting them for merges.
Scope
This specification covers the patch report specifically, as a subset of Launchpad's upstream vision.
Design
A specification should be built with the following considerations:
- The columns should show bug number, summary, importance, status, package, and patch age.
- Age that a patch has been submitted upstream but NOT yet committed.
- The report should show which distribution a patch is in that we know we can grab information from (harvest does this)
- Perhaps checkboxes for things people care about like:
- Is the patch attached to a bug that is linked upstream?
- Has the patch been submitted upstream?
- Is the bug in the ubuntu sponsorship queue already?
Outstanding Issues
The Launchpad Bugs team work for this is being tracked at the Patch Tracking page at the Launchpad dev wiki.
BoF agenda and discussion
Notes from the UDS Session follow:
Launchpad focus is going to be focusing on bridging the gap between Ubuntu and upstreams.
https://dev.launchpad.net/VersionFourDotO/Themes
When Jorge talks to upstreams, #1 complaint is not being able to find Ubuntu patches.
Wants list of patches available to be on the project front page on Launchpad.
- Sub-discussion:
- Is the project page the right place?
- beuno says that the page is mostly used by end users jml says that there's no factual basis for this and requests a citation jono observes that the project page isn't useful to end users
- Is the project page the right place?
Ubuntu has 1500+ bugs with patches, very big concern to make this information visible.
Tag on Launchpad for tracking & exposing upstream:
Similar thing for X.org - report showing bugs with patches attached, sortable by patch age: http://www2.bryceharrington.org:8080/X/Reports/patches.html http://daniel.holba.ch/harvest/handler.py?pkg=kvm
Bug for needing API for subbed pkgs: #281443
As an upstream, when you get an Ubuntu bug report, the first question you ask is "What patches is Ubuntu carrying?" (also, "And are they insane?"). Then, once you see the patch, you also need to have quality information about the context of the patch.
<jono> Launchpad is a development forge, not a front page for a project.
A patch attached to a bug is a gift to a project, then it's a top-level project. The patch needs to be visible on upstream project and package.
Need to see:
- patches attached to bugs on upstream project
- patches attached to bugs on package
- patches being carried by the package
Turning patches into merge proposals the ideal. However, an interim step good.
ACTION: look into bugs with patches stuff into the cycle.
- (deryck to estimate bugs work required.)
If LP does this, how can we measure the success:
- patch age, correlated to the position in the release cycle?
- number of patches (smaller is better)
Patches on Launchpad bugs are there for different reasons:
- A user has found a patch on a mailing list and attached
- A user has developed their own patch
- A user has found a patch on upstream and is applying it to Ubuntu.
- Developers are posting patches for users to try
Phases of implementation:
- Just have an easy list of patches on Launchpad
- Make patches that _are_ on bugs visible on the bug
- Build triaging (queue) process for patches
Some relevant bugs: https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=patch-tracking
patches not flagged - https://bugs.edge.launchpad.net/malone/+bug/232449 and a likely dup https://bugs.edge.launchpad.net/malone/+bug/172507
show patches in bug listings - https://bugs.edge.launchpad.net/malone/+bug/4780