gchristensen changed the topic of #nixos-borg to: https://www.patreon.com/ofborg https://monitoring.nix.ci/dashboard/db/ofborg?refresh=10s&orgId=1&from=now-1h&to=now "I get to skip reviewing the PHP code and just wait until it is rewritten in something sane, like POSIX shell. || https://logs.nix.samueldr.com/nixos-borg
<gchristensen> no, you can command them really quickly
<gchristensen> but they don't indicate a started eval until they start
jtojnar has quit [Ping timeout: 240 seconds]
<infinisil> Oh i see
<gchristensen> that is on my to-do :P
jtojnar has joined #nixos-borg
jtojnar has quit [Quit: jtojnar]
<{^_^}> [ofborg] @vdemeester opened pull request #310 → Add vdemeester to extra-known-users → https://git.io/fhXkG
jtojnar has joined #nixos-borg
<LnL> gchristensen: why does pos need to be propagated if everything (including maintainers) is defined in a generic file?
<{^_^}> #53959 (by ejpcmac, 2 weeks ago, open): elixir_1_8: 1.8.0-rc.1 -> 1.8.0
<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
jtojnar has quit [Quit: jtojnar]