Merge lp://staging/~ev/daisy/weighted-tests into lp://staging/daisy
Status: | Merged |
---|---|
Merged at revision: | 327 |
Proposed branch: | lp://staging/~ev/daisy/weighted-tests |
Merge into: | lp://staging/daisy |
Diff against target: |
426 lines (+283/-15) (has conflicts) 11 files modified
daisy/__init__.py (+1/-1) daisy/configuration.py (+1/-1) daisy/constants.py (+34/-0) daisy/retracer.py (+1/-1) daisy/schema.py (+13/-1) daisy/submit.py (+1/-1) daisy/submit_core.py (+1/-1) test/test_weighting.py (+125/-0) tools/build_errors_by_release.py (+17/-9) tools/unique_systems_for_errors_by_release.py (+44/-0) tools/weight_errors_per_day.py (+45/-0) Text conflict in daisy/schema.py |
To merge this branch: | bzr merge lp://staging/~ev/daisy/weighted-tests |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Brian Murray (community) | Approve | ||
Matthew Paul Thomas (community) | Needs Fixing | ||
Review via email: mp+159795@code.staging.launchpad.net |
Description of the change
This branch adds code to use the data found in ErrorsByRelease and UniqueSystemsFo
It adds a test which confirms that for a system which reported an error in 12.04 a week ago, a day after that, and a day after that, the weightings are 0, 1/90, and 2/90, respectively.
Finally, it adds a script to calculate the unique systems in SystemsForError
The SystemsForError
It's worth noting that this branch doesn't change the back-population code (tools/
> + # On the first day we had any error reports, the weighting would be 0
> + # because 0 days have past since the first report.
"passed"
> + # The second report is one day after the first and the only report of l(weights[ timestamps[ 1] / 1e6], 1/90.0) l(weights[ timestamps[ 2] / 1e6], 2/90.0)
> + # the day.
> + self.assertEqua
> +
> + # The third report is two days after the first and the only report of
> + # the day.
> + self.assertEqua
Commas after "first" would make these comments easier to understand.
> + working_date = target_date - datetime. timedelta( days=89)
>...
> + adj = min(day_difference, 90) / 90.0
These lines are far apart from each other and not obviously related. So if later we decide to change the ramp-up to 30 days, for example (improving responsiveness at the expense of spikes), you or someone else might easily change the latter while forgetting the former. I suggest using the same constant in both lines (e.g. datetime. timedelta( days=RAMPUP- 1)), and including a comment explaining what it's for.