= Vision = Launchpad focus is going to be 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 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. 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: 1. Just have an easy list of patches on Launchpad 2. Make patches that _are_ on bugs visible on the bug 3. Build triaging (queue) process for patches Some relevant bugs: https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=patch-tracking * https://bugs.edge.launchpad.net/malone/+bug/186197 * 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 = Actions = Roles: * Project Driver - Jorge. * LP Reqs and Development - Deryck. * Requirements gathering for a patch report - Jorge and Deryck * Inputs: patch-tracking tag, built-up knowledge, interviews w/ upstreams * Codify requirements in a Blueprint - Jorge * Finalize a specification for the patch report - Jorge and Deryck * Set up a graph showing the number of patches attached to bugs. Use this as a rough measure of success. -- jml * Advertise this project - Jorge *