<sphalerite>
infinisil++ I might have done this already but I need to express appreciation for your work on RFC42 again, it looks like an uphill battle to me but I really appreciate your sustained effort on it and think it's shaped into a really well thought-out and helpful design by now.
<{^_^}>
infinisil's karma got increased to 360
<sphalerite>
I'd love to see it go through, and am considering working on some of the remaining TODOs if you'd like
<qyliss>
IME the threshold is between 1000 and 5000 depending on what types of packages are likely to need rebuilding.
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-dev
betawaffle has quit [Ping timeout: 272 seconds]
sorear has quit [Ping timeout: 272 seconds]
manveru has quit [Ping timeout: 260 seconds]
ghuntley has quit [Ping timeout: 260 seconds]
kalbasit has quit [Ping timeout: 272 seconds]
vdemeester has quit [Ping timeout: 272 seconds]
claudiii has quit [Ping timeout: 272 seconds]
manveru has joined #nixos-dev
vdemeester has joined #nixos-dev
claudiii has joined #nixos-dev
kalbasit has joined #nixos-dev
ghuntley has joined #nixos-dev
betawaffle has joined #nixos-dev
sorear has joined #nixos-dev
m1cr0man has quit [Ping timeout: 272 seconds]
m1cr0man has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
<hexa->
we had 3 low effort prs in 2y, so I think we could manage :D
<hexa->
but besides planting a tree hacktoberfest probably isn't worth it
<MichaelRaskin>
We got two of them this year, though, it might be riskier now
<MichaelRaskin>
I can imagine projects where upside from opting in is likely, for Nixpkgs I am sceptical
<V>
nixpkgs requires actual experience
<hexa->
which is why low-effort prs easily stand out
init_6 has quit [Ping timeout: 265 seconds]
<kloenk>
.
<MichaelRaskin>
Frankly, a good programmer on a dare could land an update without understanding much
<hexa->
sure, because most updates are actually low-effort, no harm there
<MichaelRaskin>
Like, hmm, let's bump this version, hmm, let's try to do that thing from homepage, hmmm, it complains about hash, hmmm, replacing helps, whatever
<hexa->
you could (cd pkgs/server/home-assistant && ./update.sh) && git push
<MichaelRaskin>
It's just that Ryan has wrote a bot that makes sure such PRs are useful but their lack will not credibly becomes a relevant problem anytime soon
<MichaelRaskin>
hexa-: now finding _that_ requires more understanding
<MichaelRaskin>
Not just basic vague awareness of packaging existing, reading the homepage, and five years of grepping experience
<hexa->
hehe
<hexa->
so a good programmer then
<hexa->
either way, hacktoberfest is on a hill I want to die on
<hexa->
s/on/not/
<MichaelRaskin>
Hmmm
<MichaelRaskin>
That mental image
<MichaelRaskin>
Hacktoberfest is on a hill I want to die on, and it makes it less comfortable to live and less convenient to defend. So, demolish it.
<hexa->
it has become opt-in, so I think we're good
<hexa->
projects that have had a good experience will continue supporting it, others won't.
<MichaelRaskin>
Yeah, hopefully the worst-case scenario (which is kind of unlikely) won't materialise
<MichaelRaskin>
I do not understand why this person did not just set up a few repos and sent people there. Could get a few high-starred repos to later primote whatever project!
cole-h has joined #nixos-dev
bk16031 has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
<Mic92>
Are our experiences really that bad?
<Mic92>
I did not had a chance to look at it this year. Last year there maybe a handfull bullshit prs
__monty__ has joined #nixos-dev
<hexa->
the outrage far outweights the bad experiences :)
bk16031 is now known as bk1603
<MichaelRaskin>
We do manage to look gatekeeping enough
JJJollyjim has joined #nixos-dev
<JJJollyjim>
how much CI needs to run on a pull request before it outweighs the benefit of the tree they plant
<Mic92>
JJJollyjim: data centers usually are not that bad at wasting energy compared to your local computers, so I guess quite a bit.
<hexa->
tl;dr: datacenters in FRA are consuming one fifth of the citys total power consumption
<hexa->
biggest industry
<Mic92>
hexa-: but is not more ecological to have all data centers in one place rather spread over the country?
<hexa->
probably
r-burns has joined #nixos-dev
<JJJollyjim>
sadly those places don't often seem to be dictated by access to clean energy
<JJJollyjim>
all the datacenters in new zealand are in the north island even though the south has >99% renewable energy
<JJJollyjim>
(north is like 80% so it's not that bad)
<gchristensen>
let's put all the datacenters in iceland
<andi->
Just less datacenters but people seem to enjoy building overhead these days..
<gchristensen>
my todo app needs 11 9's of availability andi-
<andi->
gchristensen: my piece of paper has 100%
<r-burns>
quick question, any idea why a nix-build would error with "No such file or directory" for a store path even thought the path exists and is in the buildinputs?
<andi->
also: client side caching if it has to be online. I'd argue anything beyond 4 9's is not important to most
<infinisil>
r-burns: That's too little info to help
<gchristensen>
andi-: not enough kubernetes :(
<infinisil>
r-burns: Also #nixos seems like a better place
bk1603 has quit [Ping timeout: 272 seconds]
<r-burns>
ah k, thanks
<andi->
gchristensen: wasn't that the thing that has like 20% overhead for keeping itself busy? ;)
bk1603 has joined #nixos-dev
<ryantm>
I just ran a script that labeled all (I think) of the merge-conflicted PRs.
<andi->
why do we even need that? GH clearly knows which ones are conflicts, no?
<hexa->
you can now see it before diving into the pr
<ryantm>
@andi- GH doesn't expose this information in the PR search interface
<andi->
Can we file a PR to add that feature yet?
<ryantm>
andi-: No, GitHub is not open source :)
<hexa->
haha
<andi->
Why are we using it then? ;)
<andi->
Are we the product?
<ryantm>
I think we are their marketing materials for proving they can handle ridiculous repos.
<JJJollyjim>
"Look, nixpkgs is big! github.com/ice/deportees-list will work just fine!"
<hexa->
:<
<JJJollyjim>
:(
<samueldr>
ryantm: with the proper automation to remove the labels once the conflict resolved?
<ryantm>
samueldr: ofborg already removes the conflict if they push to the branch.
<ryantm>
samueldr: but, if I make my script run regularly, it claims to remove conflicts too.
<samueldr>
good
<ryantm>
The problem with ofborg's merge conflict labeling is it doesn't handle the case where master advancing introduces the conflict.
<samueldr>
yeah
<JJJollyjim>
what other type of conflict is there?
<JJJollyjim>
i guess if the pr is based on an old master at the time it's posted?
<samueldr>
old is relative, change can happen quickly :)
<samueldr>
top-level/all-packages.nix changed in master, you then open your PR, oops
<infinisil>
Because every time a new commit is pushed to master, they'd have to compute the mergability of every PR again
<infinisil>
Although, they could detect which files were changed, and do something smarter then
<infinisil>
But still, possibly very wasteful and slow
<samueldr>
wasteful? not sure
<samueldr>
it'd be quite useful
<samueldr>
with some smarts added it hopefully would have been made quick enough
<infinisil>
I guess they could sacrifice correctness by reasonably assuming that once PR's are conflicting, they stay that way until the PR is updated
<MichaelRaskin>
Being useful is apparently not mutually exclusive with being wasteful in GitHub's view
<MichaelRaskin>
File disjointness could be a reasonable heuristic, although all package additions intersect on all-packages.nix in our case
<samueldr>
I don't know if a first pass listing files being changed between versions is a good "first pass" filter that filters out conflicts well or not
<MichaelRaskin>
I guess for repositories other than Nixpkgs it could be pretty OK
<samueldr>
I guess, MichaelRaskin, file disjointness is if base...master has changes to b/b.nix and your PR has changes to a/a.nix you know it can't be a conflict?
<samueldr>
even Nixpkgs, what's the percentage of changes that touch all-packages.nix?
* samueldr
should break out the big database of diffs
<samueldr>
but uh, it's indisposed getting an SSD swap
<MichaelRaskin>
Well, it's also nice if neither master nor any of the two PRs rename a/a.nix to b/b.nix
<samueldr>
I have a way-out-of-date dump of all PRs including the diffs :)
<samueldr>
git show base...master ; git show base...PR # I assumed would be used to do the intersection
<MichaelRaskin>
I think at some point I fetched all PR heads from upstream remote… I gave up, though
<samueldr>
my methodology was much thriftier: use the API to get the diffs, save them to postgreSQL
<samueldr>
(or is it sqlite still?)
<samueldr>
the goal was to then search for `--- /path/to/file` in the text index to find a PR that touched a particular file
<samueldr>
as an experiment to something I wanted to write but never had the time to
bk1603 has quit [Ping timeout: 240 seconds]
<infinisil>
Makes me think, probably pijul's model could compute conflicting PRs faster than git's
<MichaelRaskin>
I assume that GitHub stores precomputed diffs anyway
<hexa->
if pijul ever gets ouf of its rewrite I really plan to take a look
<infinisil>
hexa-: Same
<hexa->
and nest not being open source is kinda meh
<MichaelRaskin>
Assuming general success of the rewrite, reasonable network sync solution like SSH being used to tunnel sync protocol, and lack of deliberate sabotage of third party efforts, I would assume that something open for small-scale hosting will appear
teto has joined #nixos-dev
r-burns has quit [Remote host closed the connection]
r-burns has joined #nixos-dev
<ryantm>
Correction, I did not actually label all of the merge-conflicts yet.
cole-h has quit [Ping timeout: 240 seconds]
teto has quit [Quit: WeeChat 2.9]
<ryantm>
Okay, now it is done. We have 750 merge conflict PRs, or 1/3 of all open PRs are in conflict
<samueldr>
thanks for doing it
<samueldr>
earlier this year I went through all the PRs with "WIP" in the title, tagged those WIP, and conversely, looked at PRs with the WIP tag, without the title containing WIP
<samueldr>
(or was it last year?)
<samueldr>
by these criterias we have only 1524 open PRs