Upstream report should show which reports have patches

Reported by Jorge O. Castro on 2008-10-15
2
Affects Status Importance Assigned to Milestone
Launchpad itself
High
Abel Deuring

Bug Description

The last column in the upstream report (the delta) shows which bug reports are upstreamable - I would like to also know out of those reports which ones have patches attached. I don't think it should be a seperate column, but maybe like this

(Delta)
42(4)

The first number being the existing number and the one in parenthesis being which ones of those have patches. I think the number should be red or something obvious that screams "We have a patch sitting in ubuntu that needs to go up".

Jorge O. Castro (jorge) on 2008-10-15
Changed in malone:
assignee: nobody → gmb
Graham Binns (gmb) on 2008-10-15
Changed in malone:
status: New → Triaged
Jonathan Lange (jml) on 2009-09-15
tags: added: patch-tracking
Deryck Hodge (deryck) on 2009-12-08
Changed in malone:
importance: Undecided → High
assignee: Graham Binns (gmb) → nobody
tags: added: story-patch-report
Bryce Harrington (bryce) wrote :

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.)

Bryce Harrington (bryce) wrote :

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.

Karl Fogel (kfogel) wrote :

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

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

Abel Deuring (adeuring) on 2010-02-10
Changed in malone:
assignee: nobody → Abel Deuring (adeuring)
status: Triaged → In Progress
Karl Fogel (kfogel) 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.

Deryck Hodge (deryck) 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.

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

Graham Binns (gmb) wrote :

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-----

Karl Fogel (kfogel) on 2010-02-16
tags: removed: story-patch-report
Karl Fogel (kfogel) on 2010-02-16
tags: added: patch-tracking-external
removed: patch-tracking
Changed in malone:
status: In Progress → Fix Committed
Deryck Hodge (deryck) on 2010-02-22
Changed in malone:
milestone: none → 10.02
Abel Deuring (adeuring) on 2010-03-12
Changed in malone:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers