Merge lp:~linaro-infrastructure/launchpad/team-engineering-view into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Benji York on 2012-03-26 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 15029 |
| Proposed branch: | lp:~linaro-infrastructure/launchpad/team-engineering-view |
| Merge into: | lp:launchpad |
| Diff against target: |
704 lines (+522/-12) 9 files modified
lib/lp/blueprints/model/specificationworkitem.py (+2/-1) lib/lp/bugs/interfaces/bugtask.py (+4/-1) lib/lp/bugs/model/bug.py (+1/-1) lib/lp/bugs/model/bugtasksearch.py (+12/-0) lib/lp/bugs/tests/test_bugtask_search.py (+30/-0) lib/lp/registry/interfaces/person.py (+14/-0) lib/lp/registry/model/person.py (+106/-1) lib/lp/registry/tests/test_person.py (+343/-1) lib/lp/testing/factory.py (+10/-7) |
| To merge this branch: | bzr merge lp:~linaro-infrastructure/launchpad/team-engineering-view |
| Related bugs: | |
| Related blueprints: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Benji York (community) | code | 2012-03-26 | Approve on 2012-03-27 |
|
Review via email:
|
|||
Commit Message
[bug=965446][r=benji] New IPerson methods to get assigned SpecificationWo
Description of the Change
Those new methods will be used by a new view showing the upcoming work assigned to members of a team (https:/
Both queries do some LeftJoins to bring in all the related data in a single query and avoid hitting the DB again for every returned item. The new filters to BugTaskSet.search() was a suggestion from Robert and we agreed to do the conjoined master filtering in python because the existing one in BugTaskSet.search() works only when you're filtering results for a single milestone.
Also, the plan is to not do batching on those pages as the page only includes stuff assigned to a team member *and* targeted to a milestone in the next few months. However, the new page will be guarded by a feature flag and we'll be conducting user testing to make sure we can avoid batching there.
| Guilherme Salgado (salgado) wrote : | # |
Thanks for the review, Benji!
On 26/03/12 12:41, Benji York wrote:
> Review: Approve code
>
> This branch looks good. The only think that struck me during the review
> is that the fact that milestone_
> after" and milestone_
> confusing.
>
> It may be that there is no better way to phrase that in an acceptable
> variable name.
Yeah, I'm not super happy with that either but couldn't think of a
reasonable name.
> Maybe the thing to do is to add "(inclusive)" to the docstrings
> describing the ranges for getAssignedSpec
> getAssignedBugT
I've done that change. Would you mind landing it for me?
| Robert Collins (lifeless) wrote : | # |
Just a data point: you're bring back the same people multiple times.
This is likely to be much slower than separate queries, once per type
of data being retrieved. (You will be updating your storm cache once
per person per workitem per milestone). This is *horrible* overhead.
| Benji York (benji) wrote : | # |
The recent revisions look great. The comments are especially nice.

This branch looks good. The only think that struck me during the review dateexpected_ after is really "on or dateexpected_ before is "on or before" is a little
is that the fact that milestone_
after" and milestone_
confusing.
It may be that there is no better way to phrase that in an acceptable
variable name.
Maybe the thing to do is to add "(inclusive)" to the docstrings ificationWorkIt emsDueBefore and asksDueBefore.
describing the ranges for getAssignedSpec
getAssignedBugT