pie___ has quit [Remote host closed the connection]
meizikyn has quit [Quit: WeeChat 2.3]
meizikyn has joined #nixos-dev
sir_guy_carleton has joined #nixos-dev
pxc has quit [Ping timeout: 252 seconds]
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 250 seconds]
lassulus_ is now known as lassulus
drakonis_ has quit [Read error: Connection reset by peer]
hedning has joined #nixos-dev
sir_guy_carleton has quit [Quit: WeeChat 2.2]
tv has quit [Quit: WeeChat 2.0]
tv has joined #nixos-dev
cbarrett has joined #nixos-dev
pxc has joined #nixos-dev
tv has quit [Quit: WeeChat 2.0]
tv has joined #nixos-dev
tv has quit [Client Quit]
tv has joined #nixos-dev
cranjery has joined #nixos-dev
cranjery has left #nixos-dev [#nixos-dev]
__Sander__ has joined #nixos-dev
orivej has joined #nixos-dev
hedning has quit [Remote host closed the connection]
pxc has quit [Ping timeout: 252 seconds]
hedning has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
<globin>
gchristensen: I think hydra evaluation is the biggest issue for that
<gchristensen>
yes, I think you're right
orivej has quit [Ping timeout: 246 seconds]
pie___ has joined #nixos-dev
pie__ has quit [Remote host closed the connection]
<edef>
infinisil: thank you for filing the issue re: new nixpkgs committers, by the way
<edef>
infinisil: at one point in the past i spoke to people about what the reqs were and was given some criteria (which i passed easily) and then spoke to the folks i was told to speak to and got stonewalled, and i kind of lost interest in spending a tonne of time on NixOS things since
<gchristensen>
ouch
<edef>
it's not the first time i've lost motivation/interest in contributing to a project through this mechanism, it tends to be hard to recover for me
<edef>
but i'm hopeful other people will encounter a more clearly defined process in the future and feel more welcomed?
orivej has joined #nixos-dev
<edef>
and i'm hoping that i can regain some of that motivation for myself working on a friend's fork, though thinking about this stuff right now has too many negative emotions attached to be much of a pleasant subject for me
<zimbatm>
edef: what happened exactly, did your request get ignored?
<zimbatm>
it's quite frustrating to get requests ignored
<zimbatm>
it's hard to pour a lot of energy in a project when the outcome is uncertain
<edef>
i was told "anyone who's successfully merged a nontrivial # of commits and asks ikwildrpepper for access will usually get it"
<edef>
and never got any response whatsoever from ikwildrpepper when i did ask
<gchristensen>
ouch, let's ping domenkozar :)
<edef>
this is over a year ago, i kind of lost most of my enthusiasm in the meanwhile
<edef>
i had sixty PRs then, i've done .. eight since
<domenkozar>
edef: hey
<domenkozar>
oh shi-
<domenkozar>
edef: did I forget?
<gchristensen>
seems at that time, rob was the go-to for access requests, but he'd already stepped away
<edef>
i don't remember if we ever spoke about this
<domenkozar>
current process has the flaw that it's easy to forget an email
<domenkozar>
sometimes people ping over irc, etc
<domenkozar>
so it's easy to miss
<gchristensen>
or not even see the email *looks at his growing mountain of mail*
<domenkozar>
not that it's a good excuse, but it happens
<edef>
i didn't feel confident in asking, so iirc i gave up after pinging on IRC twice got zero response
<domenkozar>
yeah I understand
<domenkozar>
nowadays I hand out access, but I hope we can make it a bit more proof in the future
<edef>
at this point it feels kind of moot for me personally, i don't actually contribute actively, it's been like two months since i did a PR
<domenkozar>
if you get to the point of contributing more, feel free to ping me :)
<edef>
most things just go into my personal tree because upstreaming is associated with .. this bunch of feels, and fixing merge conflicts when they pop up is honestly easier
<gchristensen>
I'm sorry to hear that :(
<gchristensen>
that really sucks, I'm sorry
<edef>
i want to say some kind of hopeful or positive thing but i've gone through the cycle of "contribute on regular basis to project with enthusiasm, remain in orbit around the regular contributors but in the background for procedural reasons, feel increasingly like an outsider, lose enthusiasm" for a bunch of different projects over the past 5 years
<edef>
i suspect there are more people who experience / have experienced that, and addressing this is likely to keep those people a lot happier, and make them into regular and enthusiastic contributors for years to come
<simpson>
I used to experience that, back when I cared about software.
<simpson>
Don't let a missed conversation in the past be the problem today. You're having a conversation right now.
<simpson>
Look at it this way: Contributing upstream means less stuff to keep in your private tree. That's where most of my nixpkgs PRs come from.
<edef>
i don't think that projecting one's apathy onto others by depicting their lack of it as being a deficiency is helpful
<simpson>
I'm just saying that I used to have a pattern of walking away from working on distros, and it was because I was looking for some reason to be enthusiastic and excited about contributing, rather than just contributing as a habit or as a way of cleaning house.
<edef>
a lot of people experience rejection more severely than you perhaps do, especially people from underrepresented backgrounds who don't feel particularly welcomed by default
<simpson>
I am actively attempting to unreject you from the community.
<edef>
(and often have history that increases their rejection sensitivity)
<edef>
no, i understand that you mean this as a welcoming gesture, and from a rational perspective i get that my code is probably welcome
<simpson>
(I used to feel rejection. I used to feel a lot of things. My feelings stopped working right a few years ago. I'm not telling you to not feel.)
<edef>
but unfortunately humans don't do things for purely rational reasons very often, they generally do them because they are emotionally gratifying in some way
<simpson>
Of course. I'm merely suggesting that you might find that gratification in being able to unburden yourself of some of your private patches, if nothing else.
<edef>
(my feelings stopped working somewhere around puberty, and started working again as of Puberty 2, and i don't think i've ever been as productive in the era where i didn't feel much, compared to now)
<edef>
perhaps, after i get a dozen other things fixed
<zimbatm>
same over here, I used to be much more anxious of other's perception. and it's still there today but more in the background
<zimbatm>
it's quite difficult to do open source in general I feel
<zimbatm>
so that's why we should be extra cautious as a community to others
<zimbatm>
the rust community is much more successful at that
<zimbatm>
I think it's because they have a better leadership system in place
<zimbatm>
and also dedicated community managers
<zimbatm>
whereas nixos is just a bunch of geeks that have a day job to also take care of
<zimbatm>
(or a PhD :))
<simpson>
Sure, but there are always tradeoffs. The Iron Law of Bureaucracy looms.
<edef>
even apart from the commit bit thing, things like "file PR in Aug 2017, get a single piece of frankly incorrect feedback, PR sits until March 2018, finally gets merged in May 2018" for a small patch correcting a FIXME isn't super uplifting
<zimbatm>
according to their study, psychological safety is the first factor for successful teams
<edef>
though i think there've been some things to encourage feedback/review to be done by more people since, so i hope that case will be less frequent as well
<simpson>
zimbatm: Oh jeez, it's like a cult indoctrination. :c
<zimbatm>
that article resonated quite a lot with me
<zimbatm>
I think you're missing the point simpson
<simpson>
zimbatm: FWIW I'm a Xoogler so maybe I'm a little sensitive to how this is implemented in practice.
<zimbatm>
if there is no clear process in place it causes a lot of uncertainty to people
<edef>
i'm not sure google is a good reference for a psychologically healthy working env
<zimbatm>
not everybody is a warrior
<edef>
especially judging by .. every googler/xoogler i've gotten to know so far
<simpson>
edef: We really need more people able to review PRs, I keep hearing. I'm not sure how we do that, though.
<zimbatm>
it doesn't mean that the research is invalid
<edef>
i have a lot more enthusiasm about code when i feel like i'm writing the next thing that'll get merged, rather than a discussion piece for the next months-long GitHub thread
<simpson>
That's a way to think about it. Personally my thoughts are usually like "lol fridh doesn't have time to review this crap, good thing it's not urgent"
<qyliss^work>
I'm still trying to decide what I'm going to do with systemd-less NixOS once I get it a little more stable
<srhb>
I think everyone agrees that more faster merge is more motivating, but it's hard to get a sufficiently strong (and at the same time super nice and patient) reviewer task force..
<qyliss^work>
Getting that merged upstream sounds like it would be extremely hard
<edef>
when people feel empowered they're often also happy to do more work
<qyliss^work>
So I'd be very tempted to just fork or something
<edef>
writing a quick hack that Works For Me is easy and not very motivating
<srhb>
Definitely.
<qyliss^work>
(The context here is that I have a machine running NixOS without systemd, and just about™️ everything is working)
<simpson>
qyliss^work: Exciting! You should share it, if you like.
<qyliss^work>
I have the minor setback of a hardware failure in my development machine
<qyliss^work>
But I will!
<qyliss^work>
I've posted some patches before, but they're a bit outdated now.
<srhb>
I think our best bet is still auto merges to clear up the review queue. We'll see. Regardless, nothing's gonna change really really soon.
<edef>
and writing something that'll look good in code review, that i feel proud enough of to want to spend effort on getting merged .. requires a little more motivation
<edef>
but when i feel empowered that motivation is often much easier to find
<edef>
both in terms of polishing something to begin with, and asking for / working with feedback
<qyliss>
it’s had more added to it since then, but I don’t have any way to read the drive it’s on for the next couple of days
<gchristensen>
qyliss: may I PM?
<qyliss^work>
sure!
<gchristensen>
oh dear, which one should I pick?
<qyliss^work>
oh
<qyliss^work>
this one
<qyliss^work>
if the PMs are sfw :P
<gchristensen>
hah, they most definitely are
<zimbatm>
s6-linux-init should be safely upstreamable at minimum
<qyliss^work>
I have some other packages now too
<qyliss^work>
elogind, for example
<zimbatm>
sure, all the packages
<zimbatm>
changing the module system is going to be a bit harder
<simpson>
Yeah, *that* is the real challenge. But I'm excited to see what folks come up with, since it's been something that we've imagined for a while before getting a viable implementation.
meizikyn has quit [Quit: WeeChat 2.3]
<edef>
i keep pondering how that sense of abundance and welcomeness early on in one's involvement with a project is very special and you have to like, capture that and turn it into something sustainable
<srhb>
edef: That would be very valuable knowledge for sure.
<edef>
and it's really not equivalent to one's joy in hacking on a thing, there's quite a gap between "modifying software to suit one's own needs" and "making software better together"
<zimbatm>
even in the context of nixos we are also all pursuing different goals
<zimbatm>
which makes it hard to work together
<edef>
yeah, and the ways that makes the project work honestly made a lot of the fun for me?
<zimbatm>
sorry I didn't get it
<edef>
like, having to accommodate an abundance of use cases is an interesting challenge
<zimbatm>
yeah it's difficult
<zimbatm>
and we all have to balance working on our own things while also looking at what the other people are doing
<edef>
i don't mean to emphasise difficulty here
<edef>
if one were picking the easy problems, then fixing merge conflicts from time to time is pretty easy, and nixpkgs/nixos are flexible enough that one can avoid even that a lot of the time
<zimbatm>
edef: talking about collaboration, I meant to show you my terraform+nixos integration. It's getting slowly ready to be publicly released
<edef>
mostly because i have no idea how to pick out things that are of interest
<samueldr>
tilpner: the "how much of the world I need to rebuild" indicator if I understand right?
<tilpner>
samueldr - That's the idea. Still a bunch of TODOs, but the hardest things are done
<samueldr>
neat!
<Synthetica>
Mostly useful for PR's I imagine? Or what is the intended use case?
<tilpner>
Eventually, I plan to define a buildEnv of packages, and then ask nix-weather to find me the newest nixpkgs revision that has 100% coverage for that buildEnv
<tilpner>
That would free me from waiting on nixos-unstable to bump, if nixos-unstable hangs on something I don't care about
<Synthetica>
Aaaah, nice!
<tilpner>
(NixOS tests are still an open problem)
<Synthetica>
Would be cool to also be able to couple it to a Hydra instance, to get expected build times for derivations
<tilpner>
Yes, the guix thing somehow does that
<tilpner>
But perhaps they extended their .narinfo to support that
<tilpner>
Right now, it builds a closure according to the inputDrvs of the source derivation, but it doesn't know which of these are runtime or buildtime dependencies
<tilpner>
That of course leads to a far bigger closure than it needs to be
<tilpner>
But! with the .narinfo field "References", I can probably that down by a lot