| 2010-01-11 17:56:52 |
Abel Deuring |
description |
As part of https://dev.launchpad.net/Bugs/PatchTracking, we're going to implement the "+patches" view (see a rough-cut example at http://www2.bryceharrington.org:8080/X/Reports/patches.html, and see https://wiki.ubuntu.com/Specs/LaunchpadUpstreamImprovements for the larger picture).
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://wiki.ubuntu.com/Specs/LaunchpadUpstreamImprovements, there are many places to go with such a report:
- optionally show patches carried by other distributions, if we can detect them
- 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 |
As part of https://dev.launchpad.net/Bugs/PatchTracking, we're going to implement the "+patches" view (see a rough-cut example at http://www2.bryceharrington.org:8080/X/Reports/patches.html, and see https://wiki.ubuntu.com/Specs/LaunchpadUpstreamImprovements for the larger picture).
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://wiki.ubuntu.com/Specs/LaunchpadUpstreamImprovements, there are many places to go with such a report:
- 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://daniel.holba.ch/harvest/handler.py?pkg=kvm)
- 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
|
|
