Demo Data from EDBT 2026 / reviewers in the wild / expert
Doriane Olewicki
dblp:322/7777
· DBLP profile ↗
1ranked-venue papers
1as first author
1since 2021 · last 2022
0000-0002-3285-1884ORCID · verified
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% Empirical software engineering · 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.6 | 1 | 2022 | Towards language-independent Brown Build Detection · ICSE 2022 |
Empirical software engineering › software analytics
build log analysis |
0.2 | 1 | 2022 | Towards language-independent Brown Build Detection · ICSE 2022 |
Methods — techniques the papers use, named apart from their topics
textual similarity · 0.6machine learning · 0.6
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2022 | Towards language-independent Brown Build DetectionabstractIn principle, continuous integration (CI) practices allow modern software organizations to build and test their products after each code change to detect quality issues as soon as possible. In reality, issues with the build scripts (e.g., missing dependencies) and/or the presence of "flaky tests" lead to build failures that essentially are false positives, not indicative of actual quality problems of the source code. For our industrial partner, which is active in the video game industry, such "brown builds" not only require multidisciplinary teams to spend more effort interpreting or even re-running the build, leading to substantial redundant build activity, but also slows down the integration pipeline. Hence, this paper aims to prototype and evaluate approaches for early detection of brown build results based on textual similarity to build logs of prior brown builds. The approach is tested on 7 projects (6 closed-source from our industrial collaborators and 1 open-source, Graphviz). We find that our model manages to detect brown builds with a mean F1-score of 53% on the studied projects, which is three times more than the best baseline considered, and at least as good as human experts (but with less effort). Furthermore, we found that cross-project prediction can be used for a project's onboarding phase, that a training set of 30-weeks works best, and that our retraining heuristics keep the F1-score higher than the baseline, while retraining only every 4--5 weeks. Doriane Olewicki, Mathieu Nayrolles, Bram Adams |
ICSE | 1 |