henrikingo commented on PR #127: URL: https://github.com/apache/otava/pull/127#issuecomment-3927565943
Ok thanks. So this is in the end exactly what I do too, you just thought about it and described it differently. (The Json data source is contributed by me, even :-) ...it seems I didn't contribute any documentation though. Filed #128 The CLI options are evolving for all importers, hopefully the json importer is included by whoever works on those. Anyway, in summary, what I've found works well is that you take your test result history *until* the merge-base, then add the other branch as a single data point to the end of that time series. (There seems to be both --since and --until options. Personally I deal with this outside of Otava.) And for the purposes of a PR we are only interested in whether this last data point is a change point. (--last 1) So as we evolve the user interface options in Otava, we can keep this in mind. On the mailing list I just proposed a separation of core functionality of the algorithm versus more complex management of exactly things like which commits to include in the first place, or the nature of a PR. Note by the way there is nowadays also an incremental mode, where if you have stored the state of a previous computation, you can cheaply calculate the algorithm only for the tail of the series, because new points are only appended to the end: https://github.com/apache/otava/blob/master/otava/series.py#L325-L407 ...again, this is not exposed in the CLI, and of course using it requires you have available the state from the previous computation of change points. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
