Need a "+patches" view: report lists patches attached to bugs.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
Karl Fogel |
Bug Description
As part of https:/
Overall use case:
1) Package and package group maintainers want to send patches upstream. It will be easier for them to triage patches if they can keep track of all pending patches in one place.
2) Upstream developers themselves might want to easily see what patches are available in Launchpad against their code. Having a single convenient report removes an expertise bottleneck -- once they know about the report, they can just click on that URL periodically to see what's there. (Thus, an important part of doing this is letting upstreams know it exists.)
The report should show how old the patches are, and the status of the bugs to which they are attached. It might also be useful to show the version number of the upstream release the patch is intended for, if we can divine that.
This bug is about showing a report of patches attached to bugs in Launchpad. There are other elements to the patch report story, however:
- If a bug has a branch associated with it, that should probably count as a patch for our purposes. Actually providing that branch to upstream in a form they can use is the "patch/branch equivalence" story. That will require other changes; just noting it here because if we had that other functionality ready right now, we would implement this as part of the patch report immediately.
The elements below are not in scope for this bug, but may be part of the overall story:
As discussed on https:/
- optionally show patches carried by other distributions, if we can detect them (Jorge Castro comments that he'd like this to be non-optional in the medium-to-long term; he understands it probably won't get in this cycle, and says it's okay because can use Harvest as a workaround -- see http://
- optionally show patches in the upstream tracker too (because the packager might want to know about those, even though upstream already knows)
- optionally show patches already carried by the package (are some of them the same
Related branches
- Karl Fogel (community): Approve
- Martin Albisetti (community): Approve (ui)
- Abel Deuring (community): Approve (code)
- Eleanor Berger (community): Approve (code)
-
Diff: 743 lines (+567/-9)9 files modifiedlib/canonical/launchpad/icing/style.css (+5/-1)
lib/lp/bugs/browser/bugtarget.py (+74/-2)
lib/lp/bugs/browser/configure.zcml (+8/-1)
lib/lp/bugs/interfaces/bugtarget.py (+1/-1)
lib/lp/bugs/interfaces/bugtask.py (+4/-0)
lib/lp/bugs/model/bugtarget.py (+1/-1)
lib/lp/bugs/stories/patches-view/patches-view.txt (+323/-0)
lib/lp/bugs/templates/bugtarget-patches.pt (+125/-0)
lib/lp/testing/factory.py (+26/-3)
- Eleanor Berger (community): Approve (code)
-
Diff: 204 lines (+88/-7)3 files modifiedlib/lp/bugs/browser/bugtarget.py (+8/-3)
lib/lp/bugs/browser/configure.zcml (+7/-0)
lib/lp/bugs/stories/patches-view/patches-view.txt (+73/-4)
Changed in malone: | |
status: | New → Triaged |
importance: | Medium → High |
description: | updated |
Changed in malone: | |
status: | Triaged → In Progress |
Changed in malone: | |
status: | Fix Committed → Fix Released |
Slight (but important) clarification to the #1 use case. "Package maintainers may want to send patches upstream *or include them in ubuntu*". The latter is actually the more common use case for me (and perhaps other ubuntu maintainers).
I agree seeing patches carried by other distros may be useful, but is lower importance. Regarding patches in the upstream tracker, that might be useful if those patches are attached to bug reports that have launchpad bug reports attached to them. Seeing *all* patches in the upstream tracker seems like it could get cluttery.