Show patches Ubuntu is carrying in the +patches view

[Jorge Castro]

The patches view should show what patches a distribution in lp is carrying so that it's obvious to upstreams what we're shipping. james_w thinks that since launchpad has that data when it's building a source package that that might be a good time to snag that information and stick it in the +patches view.

[Karl Fogel (kfogel)]

The current branch, https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report, can show patches in a distroseries, e.g.: https://bugs.launchpad.dev/ubuntu/warty/+patches (see the instructions in [1] for how to test that in a local Launchpad instance), and for source packages.

Is this bug really about showing the patches in the whole distribution, or just in a distroseries? If the latter, it's done; if the former, I wonder if we should spec it out a bit more, since that's potentially a *lot* of patches :-).

[1] https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428

[James Westby (james-w)]

Hi,

It's about showing patches in the whole distribution, but per-series presumably.
I think you would tend to want to look at a particular package, rather than the whole
list, but a list view that only listed packages with patches might be useful.

I think we would have something like

  /ubuntu/lucid/+source/gwibber/+patches

which would display something like

   Patch Age Some other stuff...
   01-fix-build.patch 5 weeks
   02-fix-translation-domain.patch 4 days

where each would be a link to the patch file.

This would be populated by looking at the source package as we build it (or in
a different job on the build farm after it is uploaded perhaps?), and figuring out the
individual patches (I think Scott has some code for this). It would then upload these
in to LP.

I'm not sure how this would fit for other distributions though.

Maybe this is overkill, but I think it is what Jorge is looking for with an overview of
all the patches we carry.

Thanks,

James

[Bryce Harrington (bryce)]

Yes, it would certainly be per series. Indeed, this is something which changes over time in the series, so really it wants to be specific to the version of package used.

Of course, really there are just two cases which are going to cover 95% of the needs. First is for the tip of the current series under development (Lucid currently). Second is the most recent active release (Karmic).

[Karl Fogel (kfogel)]

Notes from a conversation with Jorge Castro about this bug:

This is about the patches in the debian/patches directory of a package in a given distribution -- that's what is meant by "the patches a distribution is carrying". Note that's *not* the same as patches attached to bugs that are bugtask-linked to that package.

(This was probably already clear to Bryce and James, but not to everyone!)

Since we already show a +patches report for source packages, and it currently reports patches attached to bugs rather than patches actually included in the source package, we need to come up with a UI to also show patches being shipped in the source package. Note that these two sets of patches can overlap, which makes finding the right UI tricky.

Jorge says if he had a choice, this would be the highest triaged bug in story-patch-report right now. For example, we're supporting Lucid for 18 months. If we get a bug report about something in there, he wants to be able to see very easily what patches we're already carrying for Lucid. However, he understands that it won't makeit for the 10.02 cycle.

Steve Langashek points out that patches sent upstream will soon have http://dep.debian.net/deps/dep3/ patch tagging metadata in them -- both Debian and Ubuntu are going to follow those conventions. If some of the patches shipped with a package include that metadata, is there anything we can do with it in Launchpad? (What is Debian doing with it?)

[Deryck Hodge (deryck)]

I know Jorge wants this high importance, but it's quite a lot of work to get right and is outside the original plans for the patch report improvements we agreed, too. There's no way we can get to this within the constraints of the current work. Sorry.