Provide a way of fetching all bug_tasks on a project

[Michael Hope]

I'd like to get a list of all bug_tasks, either open or closed, on a project.

project.searchTasks(status=...) is OK, but only if all possible values of status are provided somewhere.

I currently use 'all = "New, Incomplete (with response), Incomplete (without response), Incomplete, Opinion, Invalid, Won't Fix, Expired, Confirmed, Triaged, In Progress, Fix Committed, Fix Released".split(', ')

in my own code but that's fragile.

[Robert Collins (lifeless)]

The all_bugtasks collection provides this. I'm not sure why its exported in the first instance.

However, these collections are _huge_ - hundreds of thousands of entries, and I'm extremely dubious about the value, and concerned about the cost, of exporting them.

Can you give more information on your use case?

[Michael Hope (michaelh1)]

Sure. This is for the gcc-linaro project and some of the bugs against
this project will be used to track upstream status.

For example, a bug is reported against Linaro GCC, fixed there, marked
as affecting the Linaro GCC Tracking project, and then this tracking
ticket is used to track the upstream patch status.

This means that I need all bugs in all states so that I can check bzr
commit revisions against the tracking tickets.

I can imagine getting up to hundreds of bugs.

-- Michael

On Thu, Aug 5, 2010 at 4:34 PM, Robert Collins
<email address hidden> wrote:
> The all_bugtasks collection provides this. I'm not sure why its exported
> in the first instance.
>
> However, these collections are _huge_ - hundreds of thousands of
> entries, and I'm extremely dubious about the value, and concerned about
> the cost, of exporting them.
>
> Can you give more information on your use case?
>
> ** Changed in: malone
>       Status: New => Incomplete
>
> --
> Provide a way of fetching all bug_tasks on a project
> https://bugs.launchpad.net/bugs/613713
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Launchpad Bugs: Incomplete
>
> Bug description:
> I'd like to get a list of all bug_tasks, either open or closed, on a project.
>
> project.searchTasks(status=...) is OK, but only if all possible values of status are provided somewhere.
>
> I currently use 'all = "New, Incomplete (with response), Incomplete (without response), Incomplete, Opinion, Invalid, Won't Fix, Expired, Confirmed, Triaged, In Progress, Fix Committed, Fix Released".split(', ')
>
> in my own code but that's fragile.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/malone/+bug/613713/+subscribe
>

[Robert Collins (lifeless)]

Sorry, I don't see the connection between bug state, upstream tracking
and bzr event notification.

Do you have a doc somewhere spelling out what you plan to do?

[Michael Hope (michaelh1)]

Here's the draft:
 https://wiki.linaro.org/WorkingGroups/ToolChain/PatchTracking

Short story is that every bzr revision should have a corresponding bug
which is used to track the upstream status.

-- Michael

On Thu, Aug 5, 2010 at 8:30 PM, Robert Collins
<email address hidden> wrote:
> Sorry, I don't see the connection between bug state, upstream tracking
> and bzr event notification.
>
> Do you have a doc somewhere spelling out what you plan to do?
>
> --
> Provide a way of fetching all bug_tasks on a project
> https://bugs.launchpad.net/bugs/613713
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Launchpad Bugs: Incomplete
>
> Bug description:
> I'd like to get a list of all bug_tasks, either open or closed, on a project.
>
> project.searchTasks(status=...) is OK, but only if all possible values of status are provided somewhere.
>
> I currently use 'all = "New, Incomplete (with response), Incomplete (without response), Incomplete, Opinion, Invalid, Won't Fix, Expired, Confirmed, Triaged, In Progress, Fix Committed, Fix Released".split(', ')
>
> in my own code but that's fragile.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/malone/+bug/613713/+subscribe
>

[Robert Collins (lifeless)]

I've only skimmed that for now, but have you considered using tags to
track this? Just specify no bug state to the search should get all
states, and query the bugs with the appropriate tags : this should
stop your dataset growing in an uncontrolled fashion over time.

-Rob

[Michael Hope (michaelh1)]

Hmm. Upstream is a bit funny as we need to track the state of the
patch (submitted, accepted, rejected) and the version(s) it applies
to. For example, we could find a problem in upstream 4.5 that is
fixed in trunk, released in 4.6.0, but back-ported to 4.5.3.

I'm not sure we can capture enough with tags. I'm not too happy about
abusing the project system to have a fake upstream tracking project
either but it does give us a lot of detail.

[Martin Pool (mbp)]

I think this is a real valid bug; bug 672883 is another instance of wanting a similar thing.

Making client code hardcode the list is obviously poor because it changes over time and because it's longwinded.

One pragmatic way to handle this would be to instead of status=[], instead have include_closed defaulting to False, and if that is True it included all statuses.