Conversation

Notices

1. Embed this notice
   Ludovic Courtès (civodul@toot.aquilenet.fr)'s status on Saturday, 09-Nov-2024 01:18:31 JST Ludovic Courtès

   “In this paper, we propose a methodology that uses historical build results to assist a package manager in selecting the best versions of package dependencies with an aim to improve the likelihood of a successful build.”
   https://sc24.conference-program.com/presentation/?id=pap175&sess=sess390
   https://www.osti.gov/servlets/purl/2223030

   What about providing packages that successfully build in the first place? 🤔

   • Embed this notice
     Ludovic Courtès (civodul@toot.aquilenet.fr)'s status on Saturday, 09-Nov-2024 22:54:42 JST Ludovic Courtès

     in reply to

     • Else, Someone

     @nobody For merge trains, I’d rather look at graph theory and the literature on task scheduling than follow the trend of having a probabilistic and computationally intensive hack.

   • Embed this notice
     Else, Someone (nobody@mastodon.acm.org)'s status on Saturday, 09-Nov-2024 22:54:43 JST Else, Someone

     in reply to

     @civodul I was actually thinking that if I were to partake in the LLM rush I'd try to use Hydra's build logs train a predictor that'd take a .drv graph (with access to e.g. cmake flags and potentially to inputSources) and predict build errors. If one were to achieve decent accuracy and inference cheaper than the actual builds (plausible for e.g. tensorflow), it could make for better merge trains and rolling release channels