Merge lp:~sinzui/launchpad/release-timeout-bug-513321 into lp:launchpad/db-devel
Proposed by
Curtis Hovey
Status: | Merged |
---|---|
Approved by: | Edwin Grubbs |
Approved revision: | not available |
Merged at revision: | not available |
Proposed branch: | lp:~sinzui/launchpad/release-timeout-bug-513321 |
Merge into: | lp:launchpad/db-devel |
Diff against target: |
80 lines (+19/-5) 4 files modified
lib/lp/registry/configure.zcml (+1/-0) lib/lp/registry/doc/milestone.txt (+4/-3) lib/lp/registry/interfaces/milestone.py (+9/-0) lib/lp/registry/model/milestone.py (+5/-2) |
To merge this branch: | bzr merge lp:~sinzui/launchpad/release-timeout-bug-513321 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Gary Poster (community) | release-critical | Approve | |
Edwin Grubbs (community) | code | Approve | |
Review via email: mp+18160@code.launchpad.net |
To post a comment you must log in.
Curtis Hovey has proposed merging lp:~sinzui/launchpad/release-timeout-bug-513321 into lp:launchpad/devel.
Requested reviews:
Canonical Launchpad Engineering (launchpad)
This is my branch to fix the timeout when creating a release with bugs. /bugs.edge. launchpad. net/bugs/ 341687
This is a hack, I will reopen https:/
and create an alternate implementation.
lp:~sinzui/launchpad/release-timeout-bug-513321 /bugs.launchpad .net/bugs/ 513321 implementation: gary, deryck
Diff size: 81
Launchpad bug: https:/
Test command: ./bin/test -vv -t reg.*doc/milestone
Pre-
Target release: 10.01
Fix the timeout when creating a release with bugs ------- ------- ------- ------- ------- ------- ------- ------- -----
-------
Oops OOPS-1488EA819 shows that creating a release from a milestone times out
because all the sql time is consumed looking up the bug subscribers because
all the fix committed bugs were changed to fix released.
bug.setStatus -> notify -> bug-mail -> timeout
Rules
-----
This is a feature that I personally love and is much desired by release
managers. It cannot work the way it is implemented though. We probably
want a cronscript or some other async proc that completes the bug update
after the release is created.
* Move the bug status rules to a new method that is not called.
* Update the test to verify the method.
* Leave an XXX to complete the refactoring in another branch.
QA
--
This is hard because many released were created on staging without a
timeout. Edge/lpnet is timing out.
* Create a release and verify the release is created and
that the bugs are not updated.
Lint
----
Linting changed files: registry/ configure. zcml registry/ doc/milestone. txt registry/ interfaces/ milestone. py registry/ model/milestone .py
lib/lp/
lib/lp/
lib/lp/
lib/lp/
Test
----
* lib/lp/ registry/ doc/milestone. txt eprints( ).
* Updated the test to exercise the new method closeBugsAndBlu
Implementation
--------------
* lib/lp/ registry/ configure. zcml registry/ interfaces/ milestone. py eprints( ) registry/ model/milestone .py eprints( )
* Register the new method
* lib/lp/
* Declared closeBugsAndBlu
* Left an XXX to finish this feature.
* lib/lp/
* Moved the bug status loop to closeBugsAndBlu
The attached diff has been truncated due to its size.