Demo Data from EDBT 2026 / reviewers in the wild / expert
Yelizaveta Brus
dblp:365/3931
· DBLP profile ↗
1ranked-venue papers
1as first author
1since 2021 · last 2025
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 1 · 1 first-author · 1 since 2021
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
1 paper |
Software maintenance and evolution · 77% Software testing · 23% |
Topics — the 2 heaviest of 2, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Software maintenance and evolution › release engineering
continuous integration |
0.9 | 1 | 2025 | Rechecking Recheck Requests in Continuous Integration: An Empirical Study of OpenStack · ASE 2025 |
Software testing
flaky test |
0.3 | 1 | 2025 | Rechecking Recheck Requests in Continuous Integration: An Empirical Study of OpenStack · ASE 2025 |
Methods — techniques the papers use, named apart from their topics
statistical modeling · 0.9
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2025 | Rechecking Recheck Requests in Continuous Integration: An Empirical Study of OpenStackabstractContinuous Integration (CI) is a process for automatically checking patch sets for errors. CI periodically fails due to non-deterministic (a.k.a., "flaky") behaviour. Since a patch set may not be the cause of a flaky failure, developers can issue a "recheck" command to request retesting a patch set. Developers waste time considering whether or not to issue a recheck after a CI failure. Prior work also shows that rechecks are issued liberally, wasting up to 187.4 compute years when CI continues to fail. To save developer time and avoid wasteful rechecks, we fit and analyze statistical models that discriminate between successful and failing rechecks, i.e., those rechecks that will change a failing CI run into a successful one and those that will fail again. Through an empirical study of 314,947 recheck requests from OpenStack, we find that our model can differentiate successful and failed rechecks well, outperforming baseline approaches by 23.6 percentage points in terms of AUROC (0.736).Analysis of our model suggests that, in terms of explanatory power, past behaviour of jobs, bots, and users dominate static characteristics of patch sets. Applying our model to automatically request rechecks for those predicted to succeed would have saved roughly 247 years of elapsed developer time for OpenStack. Applying our model to skip recheck requests when they are predicted to fail would avoid 86.49% of wasted rechecks, saving roughly 262 years of compute time. Yelizaveta Brus, Rungroj Maipradit, Earl T. Barr, Shane McIntosh |
ASE | 1 |