Andreas Enge <andr...@enge.fr> skribis: > Nothing prevents us from merging core-updates several times before a release. > As I see it, core-updates is there so that people tracking git master are not > forced to recompile too often.
Too often and too much. Also, changes in core-updates can potentially break more stuff. > But a change to master that forces recompilat- ion should be linked > with a merge of core-updates into master, which comes "for free" at > this moment. Right, but in master we don’t change “core” stuff like build/utils.scm, glibc, etc. Sometimes there are changes that trigger a lot of rebuild, but never as much as what we do in core-updates. Now, I agree we must find a way to avoid core-updates to last for too long. That probably means we need to agree on a time-based policy. Ideally, we’d make a new release every two months (we’re late this time), and thus have a core-updates branch living in between two releases. How does that sound? Thanks, Ludo’.
