Upstream report should show which reports have patches

There's actually 3 situations that are interesting to the "right-of" that column:

 1. A patch is attached to the launchpad bug
 2. A git/bzr/svn/etc. commit id/string is mentioned in a comment on the launchpad bug
 3. The upstream bug is marked closed

(Note that a git commit id or patch on the upstream bug report is also interesting, but to a lesser degree than these three.)

I'd suggest green or blue rather than red for the "bugs with patches" count, since having patches is a positive thing, and red sort of denotes something is broken.

From my prior comment, I think my item #2 is going to be too tricky to do in launchpad, but #3 seems like it should be straightforward, and fits well with the upstream report's mission.

For reference, the upstream report we're talking about is here:

https://edge.launchpad.net/ubuntu/+upstreamreport

Some comments from Jorge Castro about this:

He'd love for the +upstreamreport to work the same way the +patches view does, that is, filter on various Launchpad entities by going to https://launchpad.net/ENTITY_URL/+upstreamreport . I.e., you can get the upstream report for persons, teams, packages, etc.

Also, the upstream report page really needs some general love: tooltip documentation on the column names, for example. (Note how at the top of the report, there's a link to a wiki page that documents everything in the report, so the tooltip contents can just come from there.) Other UI improvements can wait; he will ask at UDS about what people really need.

I'll just remind everyone involved that making +upstreamreport be all it can be is far afield of the original agreed upon story-patch-report work. I think it's reasonable that we fix +upstreamreport as it relates to patch tracking, and if there is work that can be done easily while we're working on that aspect, then by all means let's fix it.

I do, however, want us to be deliberate about the work we take on and not try to cram in everything related to patches or upstreams and end up over-committed and under-delivering. We still have to finish the timeout and UI issues to complete the work we originally promised, which should take priority over any new work.

Cheers,
deryck

On 10 February 2010 19:03, Karl Fogel <email address hidden> wrote:
> Some comments from Jorge Castro about this:
>
> He'd love for the +upstreamreport to work the same way the +patches view
> does, that is, filter on various Launchpad entities by going to
> https://launchpad.net/ENTITY_URL/+upstreamreport .  I.e., you can get
> the upstream report for persons, teams, packages, etc.
>
> Also, the upstream report page really needs some general love: tooltip
> documentation on the column names, for example.  (Note how at the top of
> the report, there's a link to a wiki page that documents everything in
> the report, so the tooltip contents can just come from there.)  Other UI
> improvements can wait; he will ask at UDS about what people really need.
>

Speaking as Jorge's previous upstream report monkey, I'd second the
"general love" part. The upstream report is pretty hacky to begin
with, things like sorting don't work properly and there's a ton of
things that we wanted to do but never got the time to look at
properly. A bunch of bugs about the upstream report can be found under
the ubuntu-upstream-relations tag
(https://bugs.edge.launchpad.net/malone/+bugs?field.tag=ubuntu-upstream-relations),
though that contains other bugs as well.

--
Graham Binns | PGP Key: EC66FA7D

On 10 February 2010 19:28, Deryck Hodge <email address hidden> wrote:
> I'll just remind everyone involved that making +upstreamreport be all it
> can be is far afield of the original agreed upon story-patch-report
> work.  I think it's reasonable that we fix +upstreamreport as it relates
> to patch tracking, and if there is work that can be done easily while
> we're working on that aspect, then by all means let's fix it.
>

Agreed. I think there's a chance - though I don't really know how big
- that whoever has to try and fix the upstream report might find it
easier to rip chunks out of it and rewrite them. I guess it's a
question of how much we want to build on top of the kludginess that's
already there (though there's a chance I'm exaggerating just how bad
it is).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10.02.2010 20:28, Deryck Hodge wrote:
> I'll just remind everyone involved that making +upstreamreport be all it
> can be is far afield of the original agreed upon story-patch-report
> work. I think it's reasonable that we fix +upstreamreport as it relates
> to patch tracking, and if there is work that can be done easily while
> we're working on that aspect, then by all means let's fix it.

Agreed. My intention is to only add the new number proposed by Jorge (as
a link to the same page as the entire delta, bug with an additional
query parameter "field.has_patch=on"), and perhaps to add some tooltips.

>
> I do, however, want us to be deliberate about the work we take on and
> not try to cram in everything related to patches or upstreams and end up
> over-committed and under-delivering. We still have to finish the
> timeout and UI issues to complete the work we originally promised, which
> should take priority over any new work.
>
>
> Cheers,
> deryck
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFLc9mEekBPhm8NrtARAgSgAKCFeAcF7LBtMYSsxx0CQxvtOS9o5ACfRNJo
f9AuJFmdSv6JPDnKzljjqKo=
=NT5S
-----END PGP SIGNATURE-----

Fixed in db r9012 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/revision/9012>