<gchristensen>
this file is edited, but none of the variables on the derivation come from it -- so ofborg's maintainer algo doesn't consider it a candidate for pinging
<LnL>
hmm, but what about the reverse then?
<gchristensen>
what do you mean?
<LnL>
changing generic.nix would be more important to get reviews for
<infinisil>
"access to path '/nix/store/3w3yk6cllc0q65pxn898xx5bhsagr41r-globin-server' is forbidden in restricted mode"
<infinisil>
Not sure what's up with that
<gchristensen>
globin: hey can you update your borg instance?
<LnL>
should we version build requests similar to the responses?
<LnL>
that would allow only having only updated builders handle the new versions while keeping others around for builds that are not affected
<infinisil>
gchristensen: Suggestion: Instead of saying how many packages need to be rebuilt (1-10, 11-500, 501-...), make it a percentage, so (<1%, 1-20%, >20%)
<infinisil>
Makes the scale of rebuilds much cleaner imo
<gchristensen>
I don't think that makes sense, because 5,000 is a lot whether its 1% or 50%
<gchristensen>
no?
<infinisil>
Even if it's 5000, when it's only 1% it doesn't need to go to staging
<gchristensen>
it depends what you think staging is for
<LnL>
yeah that's not necessarily true
<LnL>
but another label after 500+ would be useful
<gchristensen>
let's do it
<gchristensen>
what should the rang be?
<gchristensen>
what should the range be?
<infinisil>
I mean, isn't staging to prevent lots of updates to lots of packages all wanting to get build and therefore causing unnecessary builds?
<infinisil>
To bunch together updates for the same packages sets
<infinisil>
Because if so, using percentage labels makes much more sense
<infinisil>
A bunch of 1% updates can go to master, because the chance that they update the same thing is low
<gchristensen>
my understanding is its to prevent big rebuilds hitting master for peopl eusing master
<infinisil>
Whereas a bunch of 50% updates are guaranteed to share a lot of packages with eachothwr
<infinisil>
Ah hmm yeah
<LnL>
that's one of the reasons other than just build capacity
<infinisil>
But then it makes sense too: A 1% update has the chance of 1% for a random user to have to rebuild it. Whereas a 50% update has a 50% chance
<infinisil>
This scales with the number of packages, whereas a fixed number would have to be increased over time
<infinisil>
In 10 years we might have 100000 packages. Then >500 really doesn't say all that much
<LnL>
the amount of time it takes for me to build packages locally isn't based on what's in nixpkgs but what I use
<LnL>
same goes for ofborg build timeouts, etc.
<infinisil>
Yeah, but that's no different for percentages or counts, but with 1% you at least know how high of a chance you have to be affected.
<infinisil>
Neither percentages or counts factor in build time
<infinisil>
But percentages really do make more sense imo
<infinisil>
And they're much more approachable than these high numbers :P
<gchristensen>
hrm
<LnL>
I'd argue the reverse, 1% vs 2% might be a significant difference while the numbers both look reasonable
<gchristensen>
log scale!
<LnL>
in theory we could get average build time for existing packages out of hydra
<infinisil>
LnL: Yeah but I don't propose 1% and 2% and 3%, etc. labels
<infinisil>
One label for <1%
<infinisil>
One for 1-20% and one for >20%
<infinisil>
Or so
<infinisil>
(would have to figure out what 500 builds are in percentages
<infinisil>
(without the arch duplicates then)
<LnL>
oh wait I think I might have misunderstood, do you mean only for the _large_ sets?
<infinisil>
LnL: No for all sets, 1-10 would get replaced with the similar <1% (or we could even make it <0.1%), 10-500 would become 1-20%, and >500 becomes >20%
<infinisil>
(numbers not final of course)
<LnL>
yeah don't like that, but switching to percentages for huge buckets would make sense
<infinisil>
What's the problem with the <1% range?
<LnL>
count becomes much less relevant for that
<infinisil>
Soo, you'd want to keep the label 1-10?
<LnL>
1 vs 10 vs 100 good information, <1% puts those all together and I have no clue what that even compares to
<infinisil>
That's why I said we can make it smaller to be equivalent to 1-10
<infinisil>
0.001% or whatever if necessary
<infinisil>
(Well I didn't say to make it equivalent to 1-10, but that's what I meant to say)
<infinisil>
Makes me wanna count derivations
<gchristensen>
10.rebuild-linux: 501+ should probabl ystill be applied for a while, even with greater ranges