| 2012-02-26 01:07:09 |
Eike |
bug |
|
|
added bug |
| 2012-02-26 01:07:11 |
Eike |
bug-repo-syncer: importance |
Undecided |
Wishlist |
|
| 2012-02-26 01:07:11 |
Eike |
bug-repo-syncer: milestone |
|
0.2.0 |
|
| 2012-02-26 01:07:12 |
Eike |
summary |
dummy |
Improve interface of `SyncTaskExecutor.synchronize_repos()` |
|
| 2012-02-26 01:07:12 |
Eike |
description |
dummy |
`SyncTaskExecutor.synchronize_repos()` is currently very difficult to test with real repositories.
Create interface to synchronize only a few bugs, or a single bug.
See for example bug #173. This feature would be very useful in the related test. |
|
| 2012-02-26 02:58:20 |
Eike |
description |
`SyncTaskExecutor.synchronize_repos()` is currently very difficult to test with real repositories.
Create interface to synchronize only a few bugs, or a single bug.
See for example bug #173. This feature would be very useful in the related test. |
`SyncTaskExecutor.synchronize_repos()` is currently very difficult to test with real repositories.
- Create function to discover bugs without updating them in the repositories
Create interface to synchronize only a few bugs, or a single bug.
- Create interface to synchronize only a few bugs, or a single bug.
See for example bug #173. This feature would be very useful in the related test. |
|
| 2012-02-26 18:29:00 |
Eike |
summary |
Improve interface of `SyncTaskExecutor.synchronize_repos()` |
Duplicate test bug |
|
| 2012-02-26 19:08:30 |
Eike |
summary |
Duplicate test bug |
Improve interface of `SyncTaskExecutor.synchronize_repos()` |
|
| 2012-03-02 13:29:40 |
Eike |
bug-repo-syncer: importance |
Wishlist |
Medium |
|
| 2012-03-02 13:30:53 |
Eike |
summary |
Improve interface of `SyncTaskExecutor.synchronize_repos()` |
Design for test-ability |
|
| 2012-03-02 19:05:41 |
Eike |
bug-repo-syncer: importance |
Medium |
Wishlist |
|
| 2012-03-02 19:05:41 |
Eike |
description |
`SyncTaskExecutor.synchronize_repos()` is currently very difficult to test with real repositories.
- Create function to discover bugs without updating them in the repositories
Create interface to synchronize only a few bugs, or a single bug.
- Create interface to synchronize only a few bugs, or a single bug.
See for example bug #173. This feature would be very useful in the related test. |
Design all interfaces so that they can easily tested. Also consider test
duration.
This is a high level bug to collect issues and ideas. For concrete fixes
separate bugs should be filed.
= `ApplicationMain.do_*` =
These methods should return some kind of reports that describe their
actions. Hmm???
= `SyncTaskExecutor.synchronize_repos()` =
`SyncTaskExecutor.synchronize_repos()` is currently very difficult to test with
real repositories.
* Create function to discover bugs without updating them in the repositories
* Create interface to synchronize only a few bugs, or a single bug.
See for example bug #173. This feature would be very useful in the related
test.
= `*Controller.get_recent_changes` =
Tests for these methods are currently quite slow because they
download many bugs.
To test these methods they currently download changes from a fixed
date. Then the test function searches for certain bugs in the list
of returned bugs. As the number of bugs increases over time, the
test gets slower and slower. This problem would be alleviated if
the function returned only IDs.
== Strategy 1 ==
Tests for these methods could be sped up after switching to
"Launchpad-staging": The bugs could be created immediately before
the test. Everything in staging is deleted after some weeks. The test for Trac could delete its bugs at the end.
== Strategy 2 ==
Change method's return value to list of bug IDs.
Research this with `LaunchpadController`, the design of Launchpadlib makes it
hard to predict the performance of the changed design. Launchpadlib returns an
iterator over bug-tasks that probably downloads the tasks when their ID
`self_link` is taken. |
|
| 2012-03-07 01:14:24 |
Eike |
bug-repo-syncer: milestone |
0.2.0 |
0.3.0 |
|
| 2012-03-25 22:50:20 |
Eike |
description |
Design all interfaces so that they can easily tested. Also consider test
duration.
This is a high level bug to collect issues and ideas. For concrete fixes
separate bugs should be filed.
= `ApplicationMain.do_*` =
These methods should return some kind of reports that describe their
actions. Hmm???
= `SyncTaskExecutor.synchronize_repos()` =
`SyncTaskExecutor.synchronize_repos()` is currently very difficult to test with
real repositories.
* Create function to discover bugs without updating them in the repositories
* Create interface to synchronize only a few bugs, or a single bug.
See for example bug #173. This feature would be very useful in the related
test.
= `*Controller.get_recent_changes` =
Tests for these methods are currently quite slow because they
download many bugs.
To test these methods they currently download changes from a fixed
date. Then the test function searches for certain bugs in the list
of returned bugs. As the number of bugs increases over time, the
test gets slower and slower. This problem would be alleviated if
the function returned only IDs.
== Strategy 1 ==
Tests for these methods could be sped up after switching to
"Launchpad-staging": The bugs could be created immediately before
the test. Everything in staging is deleted after some weeks. The test for Trac could delete its bugs at the end.
== Strategy 2 ==
Change method's return value to list of bug IDs.
Research this with `LaunchpadController`, the design of Launchpadlib makes it
hard to predict the performance of the changed design. Launchpadlib returns an
iterator over bug-tasks that probably downloads the tasks when their ID
`self_link` is taken. |
Design all interfaces so that they can easily tested. Also consider test
duration.
This is a high level bug to collect issues and ideas. For concrete fixes
separate bugs should be filed.
= `ApplicationMain.do_*` =
These methods should return some kind of reports that describe their
actions. Hmm???
= `SyncTaskExecutor.synchronize_repos()` =
`SyncTaskExecutor.synchronize_repos()` is currently very difficult to test with
real repositories.
* Create function to discover bugs without updating them in the repositories
* Create interface to synchronize only a few bugs, or a single bug.
See for example [@[@BUGLINK "bug #173"@lp @]@]. This feature would be very useful in the related
See for example [@[@BUGLINK "bug #173"@trac @]@]. This feature would be very useful in the related
test.
= `*Controller.get_recent_changes` =
Tests for these methods are currently quite slow because they
download many bugs.
To test these methods they currently download changes from a fixed
date. Then the test function searches for certain bugs in the list
of returned bugs. As the number of bugs increases over time, the
test gets slower and slower. This problem would be alleviated if
the function returned only IDs.
== Strategy 1 ==
Tests for these methods could be sped up after switching to
"Launchpad-staging": The bugs could be created immediately before
the test. Everything in staging is deleted after some weeks. The test for Trac could delete its bugs at the end.
== Strategy 2 ==
Change method's return value to list of bug IDs.
Research this with `LaunchpadController`, the design of Launchpadlib makes it
hard to predict the performance of the changed design. Launchpadlib returns an
iterator over bug-tasks that probably downloads the tasks when their ID
`self_link` is taken. |
|
| 2012-03-27 09:29:32 |
Eike |
bug-repo-syncer: milestone |
0.3.0 |
0.4.0 |
|
| 2012-03-27 09:29:33 |
Eike |
description |
Design all interfaces so that they can easily tested. Also consider test
duration.
This is a high level bug to collect issues and ideas. For concrete fixes
separate bugs should be filed.
= `ApplicationMain.do_*` =
These methods should return some kind of reports that describe their
actions. Hmm???
= `SyncTaskExecutor.synchronize_repos()` =
`SyncTaskExecutor.synchronize_repos()` is currently very difficult to test with
real repositories.
* Create function to discover bugs without updating them in the repositories
* Create interface to synchronize only a few bugs, or a single bug.
See for example [@[@BUGLINK "bug #173"@lp @]@]. This feature would be very useful in the related
See for example [@[@BUGLINK "bug #173"@trac @]@]. This feature would be very useful in the related
test.
= `*Controller.get_recent_changes` =
Tests for these methods are currently quite slow because they
download many bugs.
To test these methods they currently download changes from a fixed
date. Then the test function searches for certain bugs in the list
of returned bugs. As the number of bugs increases over time, the
test gets slower and slower. This problem would be alleviated if
the function returned only IDs.
== Strategy 1 ==
Tests for these methods could be sped up after switching to
"Launchpad-staging": The bugs could be created immediately before
the test. Everything in staging is deleted after some weeks. The test for Trac could delete its bugs at the end.
== Strategy 2 ==
Change method's return value to list of bug IDs.
Research this with `LaunchpadController`, the design of Launchpadlib makes it
hard to predict the performance of the changed design. Launchpadlib returns an
iterator over bug-tasks that probably downloads the tasks when their ID
`self_link` is taken. |
Design all interfaces so that they can easily tested. Also consider test
duration.
This is a high level bug to collect issues and ideas. For concrete fixes
separate bugs should be filed.
= `ApplicationMain.do_*` =
These methods should return some kind of reports that describe their
actions. Hmm???
= `SyncTaskExecutor.synchronize_repos()` =
`SyncTaskExecutor.synchronize_repos()` is currently very difficult to test with
real repositories.
* Create function to discover bugs without updating them in the repositories
* Create interface to synchronize only a few bugs, or a single bug.
= `*Controller.get_recent_changes` =
Tests for these methods are currently quite slow because they
download many bugs.
To test these methods they currently download changes from a fixed
date. Then the test function searches for certain bugs in the list
of returned bugs. As the number of bugs increases over time, the
test gets slower and slower. This problem would be alleviated if
the function returned only IDs.
== Strategy 1 ==
Tests for these methods could be sped up after switching to
"Launchpad-staging": The bugs could be created immediately before
the test. Everything in staging is deleted after some weeks. The test for Trac could delete its bugs at the end.
== Strategy 2 ==
Change method's return value to list of bug IDs.
Research this with `LaunchpadController`, the design of Launchpadlib makes it
hard to predict the performance of the changed design. Launchpadlib returns an
iterator over bug-tasks that probably downloads the tasks when their ID
`self_link` is taken. |
|
| 2012-04-01 10:40:50 |
Eike |
bug-repo-syncer: milestone |
0.4.0 |
0.5.0 |
|
| 2012-04-01 10:42:26 |
Eike |
description |
Design all interfaces so that they can easily tested. Also consider test
duration.
This is a high level bug to collect issues and ideas. For concrete fixes
separate bugs should be filed.
= `ApplicationMain.do_*` =
These methods should return some kind of reports that describe their
actions. Hmm???
= `SyncTaskExecutor.synchronize_repos()` =
`SyncTaskExecutor.synchronize_repos()` is currently very difficult to test with
real repositories.
* Create function to discover bugs without updating them in the repositories
* Create interface to synchronize only a few bugs, or a single bug.
= `*Controller.get_recent_changes` =
Tests for these methods are currently quite slow because they
download many bugs.
To test these methods they currently download changes from a fixed
date. Then the test function searches for certain bugs in the list
of returned bugs. As the number of bugs increases over time, the
test gets slower and slower. This problem would be alleviated if
the function returned only IDs.
== Strategy 1 ==
Tests for these methods could be sped up after switching to
"Launchpad-staging": The bugs could be created immediately before
the test. Everything in staging is deleted after some weeks. The test for Trac could delete its bugs at the end.
== Strategy 2 ==
Change method's return value to list of bug IDs.
Research this with `LaunchpadController`, the design of Launchpadlib makes it
hard to predict the performance of the changed design. Launchpadlib returns an
iterator over bug-tasks that probably downloads the tasks when their ID
`self_link` is taken. |
Design all interfaces so that they can easily tested. Also consider test
duration.
This is a high level bug to collect issues and ideas. For concrete fixes
separate bugs should be filed.
= `ApplicationMain.do_*` =
These methods should return some kind of reports that describe their
actions. Hmm???
= `*Controller.get_recent_changes` =
Tests for these methods are currently quite slow because they
download many bugs.
To test these methods they currently download changes from a fixed
date. Then the test function searches for certain bugs in the list
of returned bugs. As the number of bugs increases over time, the
test gets slower and slower. This problem would be alleviated if
the function returned only IDs.
== Strategy 1 ==
Tests for these methods could be sped up after switching to
"Launchpad-staging": The bugs could be created immediately before
the test. Everything in staging is deleted after some weeks. The test for Trac could delete its bugs at the end.
== Strategy 2 ==
Change method's return value to list of bug IDs.
Research this with `LaunchpadController`, the design of Launchpadlib makes it
hard to predict the performance of the changed design. Launchpadlib returns an
iterator over bug-tasks that probably downloads the tasks when their ID
`self_link` is taken. |
|
