gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
tilpner has quit [Ping timeout: 272 seconds]
eadwu has joined #nixos-dev
<ma27> does anybody want to review the following (relatively small) nix pr: https://github.com/NixOS/nix/pull/2266 (it would be awesome to see this in one of the next releases :) )
<{^_^}> nix#2266 (by Ma27, 26 weeks ago, open): nix search: allow `-a` for attribute-only searches
eadwu has quit [Ping timeout: 246 seconds]
eadwu has joined #nixos-dev
init_6 has joined #nixos-dev
init_6 has quit [Ping timeout: 246 seconds]
pie__ has quit [Remote host closed the connection]
pie__ has joined #nixos-dev
init_6 has joined #nixos-dev
eadwu has quit [Ping timeout: 250 seconds]
asymmetric has quit [Ping timeout: 250 seconds]
eadwu has joined #nixos-dev
eadwu has quit [Ping timeout: 245 seconds]
eadwu has joined #nixos-dev
eadwu has quit [Read error: Connection reset by peer]
eadwu has joined #nixos-dev
orivej has quit [Ping timeout: 244 seconds]
lassulus_ has joined #nixos-dev
pie__ has quit [Remote host closed the connection]
pie__ has joined #nixos-dev
lassulus has quit [Ping timeout: 250 seconds]
lassulus_ is now known as lassulus
eadwu has quit [Ping timeout: 246 seconds]
worldofpeace has quit [Ping timeout: 246 seconds]
sir_guy_carleton has quit [Quit: WeeChat 2.2]
Cale has quit [Ping timeout: 260 seconds]
Cale has joined #nixos-dev
init_6 has quit [Ping timeout: 240 seconds]
init_6 has joined #nixos-dev
pie__ has quit [Remote host closed the connection]
pie__ has joined #nixos-dev
init_6 has quit [Ping timeout: 246 seconds]
init_6 has joined #nixos-dev
init_6 has quit [Ping timeout: 250 seconds]
FRidh has joined #nixos-dev
phreedom has quit [Ping timeout: 256 seconds]
pie__ has quit [Ping timeout: 252 seconds]
init_6 has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
<timokau[m]> >1k open pull requests o.O
<Profpatsch> oops
<Profpatsch> timokau[m]: What’s the problem for that?
<Profpatsch> Congestion of maintainers? Like far too few people are mentioned to have time to act/review on thees?
<Profpatsch> Or just that nobody is mentioned, so PRs are not reviewed at all?
<Profpatsch> We have a big systemic problem.
<Profpatsch> (to be honest I invest exactly 0 time reviewing PRs I’m not mentioned in)
<Profpatsch> gchristensen is working on adding maintainer mentions to ofborg, so that’s a good first step.
<Profpatsch> But is that enough?
orivej has quit [Ping timeout: 268 seconds]
<bennofs[m]> gchristensen: if we added the builds.json to the channel binary cache, then that bloom filter would be easy to build...
<timokau[m]> Profpatsch: I can't say for sure. I still hope my review rfc (https://github.com/NixOS/rfcs/pull/30) could help, but nobody got around to implementing the necessary ofBorg support yet
<{^_^}> rfcs#30 (by timokau, 20 weeks ago, open): Formalize review workflow
<arianvp> Mic92:
<arianvp> building rocksdb works in nix-shell but fails in nix-build
<Profpatsch> timokau[m]: idk, that sounds like a technical solution to a social problem, namely: people only have so much time.
orivej has joined #nixos-dev
<Profpatsch> If we assume every maintainer is willing to spend 1 hour per week of their free time to review and merge stuff, we need at least 20–30 active maintainers I’d assume.
<Profpatsch> And that’s just for small version upgrades.
<FRidh> pretty sure that currently way more than 30h per week is put in on reviewing PR's
<Profpatsch> FRidh: Probably, yes. But do you think most open PRs take more than 10 minutes to review?
<Profpatsch> I’d wager there’s 90% trivial stuff and only small amounts of non-trivial PRs.
<Profpatsch> And focus should be put on merging all the trivial stuff in less than a week at least.
<Profpatsch> Because otherwise contributors get discouraged.
<FRidh> Profpatsch: depends on what you want to cover in your review. Small version bumps can typically be handled in a couple of minutes, tops. Most PR's are like these. While trivial, I am not sure whether we should spend too much time on these. Those wanting a rolling release can put in that effort. I don't think it's worth it, despite wasting a lot of time on them.
<Profpatsch> FRidh: I agree that updating stuff on-demand is more worthwhile than being always on the newest release.
<Profpatsch> But I guess most first-time contributions are trivial patches like these, and if nobody reacts we just lost a potential contributor.
orivej has quit [Ping timeout: 240 seconds]
init_6 has quit []
FRidh has quit [Read error: Connection reset by peer]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
<arianvp> Profpatsch: do you think automation will help?
<arianvp> gchristensen: the bloomfilter idea is neat
<arianvp> is that to stop incurring costs of slow 404s?
<gchristensen> yeah
<gchristensen> not sure it is actually worth it, but yeah
<arianvp> It's an elegant solutionb
<arianvp> but is 404s actually that expensive currently?
<Profpatsch> arianvp: idk, automation only helps when it removes steps of work people are already doing.
sir_guy_carleton has joined #nixos-dev
<Profpatsch> Automating something that is not already practiced is normally not as effective.
<arianvp> I think the bloom filter is also useful for local development. say when im in a plane. such that nixos wont try to fetch things that are defenitely not there
<Profpatsch> arianvp: So e.g. if we say “we want to make sure that every first-time-contributor (under 10 commits) gets priority reviews and is invited to do maintenance on their 10th commit” then somebody needs to start doing it manually.
<arianvp> because now if I work say on a local haskell project, I always manually need to enable local builds
<arianvp> but with bloom filter, we could make that decision automatic, and it would be sound
<Profpatsch> And if it’s a worthwhile thing, then we can automate (e.g. by adding tags and creating a list of issues and/or notifications).
<gchristensen> arianvp: do you know C++? :)
<arianvp> barely
<gchristensen> same :D
<arianvp> I know C++ because I know rust
<arianvp> :P
<arianvp> but the Nix codebase seems pretty okay-ish
<gchristensen> we'd need the bloom filter to be generated server-side in a serialized format -- not a list of paths
<arianvp> sometimes I wish Nix was written in Go
<gchristensen> the Nix codebase is pretty good c++
<gchristensen> but we can sort out that part later, if support for loading a bloom filter per cache is added to Nix I can generate a serialized bloom filter
<arianvp> shouldn't be too hard
<arianvp> only have to edit BinaryCacheStore class I think
<arianvp> and of course some tooling to generate the bloom filter?
<gchristensen> well skipping the generation
<gchristensen> just the part about Nix using it
<gchristensen> so after a scientific look at 3 pull requests, ofborg's maintainer algo seems to be doing the right thing
<arianvp> Profpatsch: another problem I see is that we never _close_ prs
<arianvp> If a PR goes nowhere, and needs signifcant work to even be rebased on master, I Dont see why we shouldnt' close it
<gchristensen> PR authors can reopen a closed PR, so I agree
<arianvp> I think there's at least 100 PRs that could be closed for this reason
<arianvp> Kubernetes has an auto-close bot on PRs for this
<arianvp> >6 months inactivity && conflict with master => autoclose
<gchristensen> interesting
<gchristensen> that seems good
<arianvp> and then the user can reopen it again if he found it important
<arianvp> Gitlab takes the same approach
<arianvp> speaking of stale PRs
<arianvp> i'm pretty sure we can close this one: https://github.com/NixOS/nixpkgs/pull/3021
<{^_^}> #3021 (by chrisfarms, 4 years ago, open): Improvements for declarative nixos containers
orivej has joined #nixos-dev
<gchristensen> ok I'm going to make ofborg request reviews maintainers. its doing the right thing on every PR I'm seeing.
<timokau[m]> +1
orivej has quit [Ping timeout: 240 seconds]
<gchristensen> oh. to do that, I first have to teach my github client how to do it :)
<arianvp> Messing around a bit with Github queries
<arianvp> is:open is:pr label:"2.status: merge conflict" created:<2017-06-01
<arianvp> all PRs with merge conflicts, that havent been merged for more than 1.5 years
<timokau[m]> gchristensen Github client?
<gchristensen> the rust client for github, Hubcaps, but my forked version
<timokau[m]> Oh so its an api
<gchristensen> yea
<timokau[m]> I was thinking a neat TUI client
<arianvp> gchristensen: https://github.com/probot/stale
<gchristensen> neat
<arianvp> I think it's a good idea.
<arianvp> where do I propose this? nixpkgs? rfcs?
<timokau[m]> I think somebody already "proposed" it on discourse once
<timokau[m]> Problem is that you need to get the attention of someone who has admin rights on the repo
<gchristensen> I think an RFC might be good
<gchristensen> to properly weigh the pros and cons and costs it'll have
<gchristensen> looks like I can't request a review via the API, I can only assign the PR
<gchristensen> and assigning doesn't work because you can't assign a PR to someone who isn't a member
<gchristensen> well that was a good, fun try
<timokau[m]> I think just @mentioning them should be good enough as long as the api doesn't allow anything better
<timokau[m]> A bit spammy, but better than nothing
<gchristensen> that is pretty complicated, because a PR may be evaluated many times
<gchristensen> so each time I'd have to scan each comment for people already mentioned and not mention them. it is doable, but a bit annoying
<gchristensen> where was that when I was looking for it!
<gchristensen> 😻
<timokau[m]> For some reason not listed under pull requests
<gchristensen> thank you timokau[m]!
<gchristensen> "Note: You can now use emoji in label names, add descriptions to labels, and search for labels in a repository. See the blog post for full details. To access these features and receive payloads with this data during the preview period, you must provide a custom media type in the Accept header:" man they really phoned it in when writing this doc: unlinked from the pull page, bad copy :P
<timokau[m]> Thank *you* for doing the hard part and actually implementing it
<timokau[m]> Yeah I was wondering what the relevance of that note was
<gchristensen> thatis copy-pasted from the beta note about adding emojis
FRidh has joined #nixos-dev
<gchristensen> bummer, ofborg didn't catch this: https://github.com/NixOS/nixpkgs/pull/53281/files but of course it didn't
<FRidh> gchristensen: https://github.com/NixOS/nixpkgs/pull/53313 there are potential maintainers as recognized by ofborg, but they're not pinged.
<{^_^}> #53313 (by r-ryantm, 1 hour ago, open): jackett: 0.10.504 -> 0.10.566
<arianvp> gchristensen: I dont have the writing skills to write a coherent RFC though
<FRidh> or is it because the maitnainer is already pingen in the main msg?
<LnL> I think that was intentional
<LnL> (for now)
<gchristensen> FRidh: right now it is is "no-op" mode, just posting the list in a Details link in the Checks
<FRidh> ok
<gchristensen> I didn't want to accidentally spam a million people
<FRidh> makes sense
<gchristensen> FRidh: it turns out first I have to extend the github api client to support review requests before I can do it, anyway :)
<FRidh> gchristensen: instead of review requests, you already have the possibility to post a comment, right? Maybe that's sufficient for the next step.
<gchristensen> that is a bit more complicated, because each PR is evaluated many times. each time, I'd have to scan each comment for people already mentioned and not mention them. it is doable, but a bit annoying
<gchristensen> and I'm trying to get rid of comments :)
<FRidh> Right. With such complications it's no longer a shortcut
<gchristensen> and it is only about 100loc to add it to hubcaps :)
<LnL> heh
<FRidh> this is pretty useless: error: attribute 'pname' missing, at /home/freddy/Code/libraries/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:84:54
<FRidh> that's the whole trace
<FRidh> so...which drv
<gchristensen> where is that?
<FRidh> a branch of mine. Made a bunch of changes, testing eval locally
<gchristensen> ouch
<Profpatsch> FRidh: no luck with --show-trace?
<FRidh> Profpatsch: nope this was output using --show-trace
<FRidh> Note I found which part of my changes is causing it. Looking now whether make-derivation can be improved here
sir_guy_carleton has quit [Ping timeout: 246 seconds]
<domenkozar> gchristensen: I think elm development with Nix is a breeze now, if you ever consider returning to package browser rewrite :)
<gchristensen> yay!
<gchristensen> I saw that :0
<domenkozar> https://github.com/NixOS/nixpkgs/pull/53326 closes the last bit
<{^_^}> #53326 (by domenkozar, 4 minutes ago, open): Elm: automate packaging with elm2nix
pie__ has joined #nixos-dev
<gchristensen> good news, y'all, ofborg will now ping maintainers on PRs where <10 maintainers are identified.
<LnL> gchristensen++
<{^_^}> gchristensen's karma got increased to 57
<domenkozar> gchristensen++
<{^_^}> gchristensen's karma got increased to 58
<gchristensen> (at least, it will once the deploy finishes ... tick tock, buildkite!)
<timokau[m]> gchristensen++
<{^_^}> gchristensen's karma got increased to 59
<nbp> For posteriryt, I am quoting my-self about fix-point: “This is like having a time machine to tell you what is the output, without introducing a paradox :)”
<nbp> ^ posterity
<gchristensen> damn. you can only request reviewers of collaborators, so maintainers who aren't members can't be requested
worldofpeace has joined #nixos-dev
phreedom has joined #nixos-dev
<infinisil> gchristensen: Huh, is this a limitation of github?
<gchristensen> yeah
<infinisil> Ohh yeah it doesn't work manually either
<gchristensen> right
<gchristensen> I have a solution in mind, but I'm still looking in to it
<domenkozar> "quick, implement reviewing by reusing the assignment function, it's just a 1 day task"
<infinisil> I wouldn't mind it being a comment with all the pings, similar to the previous bot
<domenkozar> is how I imagine reviewing widget to appear :D
<gchristensen> lol
<FRidh> we could create a nixpkgs team with read-only access, and then with a little script and priviliged user add all package maintainers to it. Ugly but gets it further
<samueldr> domenkozar: your scenario makes more sense than you give yourself credit for: only project members can assign reviewers
<samueldr> a non-member contributor cannot ask for a reviewer directly :/
<gchristensen> FRidh: exactly my thought :)
<samueldr> an annoying bit with the R/O team is that everyone in the maintainers list will appear as "Member" anywhere in the NixOS org :/
<domenkozar> samueldr: I know, the feature was never thought through UX wise on github side
<gchristensen> read grants creating repos? :o
<samueldr> there's something to further restrict, at least https://stuff.samueldr.com/screenshots/2019/01/20190103134045.png
<gchristensen> one problem with putting everyone in a team is they'll all have to have 2fa
<gchristensen> even though they're not granted any special privileges
<FRidh> well, they can continue without 2fa right, they just won't be part of the team then..?
<gchristensen> yeah
<FRidh> decline and move on
<FRidh> kind of gives us a good idea as well what people are willing to do
<gchristensen> ok, I think we'll do that then
<FRidh> for every merged r-ryantm PR three new ones are opened :/
<gchristensen> his bot is the literal hydra
<gchristensen> chop one head and nine hundred more show up
<FRidh> yea
phreedom has quit [Ping timeout: 256 seconds]
phreedom has joined #nixos-dev
Mic92 has quit [Quit: WeeChat 2.3]
Mic92 has joined #nixos-dev
sir_guy_carleton has joined #nixos-dev
sir_guy_carleton has quit [Ping timeout: 258 seconds]
sir_guy_carleton has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
<gchristensen> I'm getting word that FreeBSD gets a substantial kernel compile speedup by using a parallelized linker
<gchristensen> I wonder if that is something the linux kernel could be coaxed in to doing
<worldofpeace> ooh just got "GrahamcOfBorg requested your review on this pull request" nice :)
<gchristensen> :) I posted about it over here: https://www.patreon.com/posts/requesting-of-23731342
sir_guy_carleton has quit [Quit: WeeChat 2.2]
<worldofpeace> Much praise to you gchristensen yet again :D
<gchristensen> ^.^
<dtz> freebsd uses LLD, perhaps we should give that a go as well? :D ;)
pie__ has quit [Ping timeout: 250 seconds]
jtojnar has quit [Quit: jtojnar]
<Mic92> when the kernel compiles with clang, we could use it on all platforms
<LnL> I'm pretty sure more than 70% of the "darwin conditionals would disappear if we used clang by default
<gchristensen> I'll write a program tonight to sync a github team with the maintainer list and we'll get that going tomorrow I think
<LnL> still confused why that's necessary
<samueldr> no one else is a bit concerned by the fact that "Member" will be shown on everyone in that team's comments and contributions?
<gchristensen> is that a concern?
<samueldr> not sure it is, thus "a bit"
<gchristensen> well let's talk about it
<samueldr> it might could be abused to attribute more confidence to a member in a social engineering aspect?
<samueldr> not directly related, but think about how "coretemp" would be Member
<gchristensen> yikes
<gchristensen> probably the thing to do is make the Nixpkgs Committers team Public, and then make a separate team called Nixpkgs Package Maintainer
<gchristensen> I wonder if there are fancier tricks we can use
<samueldr> I'm thinking the good ol' mention thing is probably the better approach :/
<LnL> why do people need to have a contributor status?
<samueldr> unless there are downsides to its UX that are not obvious?
<samueldr> only members of an org can be asked to review a PR
<gchristensen> we can't assign issues to them or request reviews
<gchristensen> https://github.com/NixOS/nixpkgs/pulls/review-requested/grahamc this is a very nice screen which would be cool to enable
<LnL> if they don't use github there's no point in assigning it
<LnL> oh, contributor is not enough?
<gchristensen> right, they need to be a Collaborator
<LnL> I get it now, got those confused as the same thing
<samueldr> as far as github is concerned: user has a commit in repo? contributor and that's pretty much it
<samueldr> and AFAICT there's no way to make some kind of additional level
<gchristensen> well, we can add them to a team which grants them no special privileges
<gchristensen> that is the next level, afaik
<samueldr> yeah, let's add "without making them member of the org"
<LnL> that's not possible I think
<LnL> the workaround is becoming a member without actual permissions
<samueldr> yeah, circling back to my initial "no one else is a bit concerned by the fact that "Member" will be shown on everyone in that team's comments and contributions?"
<gchristensen> turning that on its head, how cool will it be to be a contributor and get to wear then nixos badge with pride
<samueldr> I'm not sure there's concern to be had, but doubts persist
<samueldr> yeah, that would be neat
<samueldr> hmmm, that makes me think: epic does something similar
<gchristensen> w.r.t. your concerns with coretemp, is your concern: they're rude on other projects and will carry the nixos symbol and reflect poorly on us?
<LnL> so the "member" badge would imply maintainer, not committer
<samueldr> yeah
<gchristensen> or, is your concern: they're rude on our project and will carry extra weight as a Member when being rude to another contributor?
<samueldr> gchristensen: more the latter than the former
<gchristensen> well then we'd better strip them of their maintainership status
<gchristensen> (conveniently, I had that answer ready for both ;))
<samueldr> but my initial thoughts were less about inter-personal within nixpkgs, but more about external
<LnL> if that's a concern we could make maintainers mean a bit more then it does now
<gchristensen> I agree
<gchristensen> I also think with the rolling out of this ofborg patch, being a maintainer *does* mean more
<gchristensen> automatically
<LnL> at the moment it basically means nothing
<LnL> yeah, exactly
<samueldr> and just to be clear: I'm not even sure there's concern to be had, but just thinking there could be ways to be abused, I'm sure more abuse could be thought of along the way
<samueldr> and it all rely on how the principle of people are the softest link any social engineering attack :/
* samueldr butchered that sentence
<samueldr> it rlies on the principle, just as with social engineering, that people are the softest link (weakest if you prefer the proper word)
<samueldr> though yeah, if Member is easy to come by, then it won't have as much meaning, so there wouldn't be any weight to abuse?
<samueldr> and the benefits outweight the hypothetical non-issues
<gchristensen> yeah, I'm not sure ... hmm
<gchristensen> time to do some experiments
<LnL> maybe this is a good argument for a COC
<LnL> maintainers status can be revoked
<gchristensen> +1
pie__ has joined #nixos-dev
<gchristensen> ok, experiments show members of an org where their membership isn't Public aren't showed as Members, see: https://github.com/eb6cb83a-cf75-4e88-a11a-ce117467d8ae/4ec54bd9-c707-4238-bc46-48596d6d7659/issues/1
<{^_^}> eb6cb83a-cf75-4e88-a11a-ce117467d8ae/4ec54bd9-c707-4238-bc46-48596d6d7659#1 (by grahamc, 18 minutes ago, open): 925be7b2-40d9-4390-9d56-5f2d13083589
<gchristensen> (both samueldr and LnL are members)
<gchristensen> the trouble is the users can make themselves public, but that can be un-done... I've asked github support if it can be prevented.
<gchristensen> samueldr: ^ given this info, and without an answer to my support question, any concerns?
<samueldr> I don't think the concerns are that important, considering how there's no tangible issue, just hypotheticals
<samueldr> I thought others would speak up if they had any tangible concerns, looks like there are none
<gchristensen> yes, I agree
<gchristensen> in this TZ, anyway :)
<samueldr> I did speak up earlier (~13h30 in this TZ)
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 250 seconds]
orivej has joined #nixos-dev
worldofpeace has quit [Ping timeout: 250 seconds]
jtojnar has joined #nixos-dev