orivej has quit [Quit: No Ping reply in 180 seconds.]
<sphalerite>
500 Internal Server Error If you are the administrator of this website, then please read this web application's log file and/or the web server's log file to find out what went wrong.
<sphalerite>
%)
<spacekookie>
Hmm
orivej has joined #nixos-dev
<sphalerite>
Mic92: hm, no proper cert? :(
<sphalerite>
and it's not on mumble.nixos.community? :(
<spacekookie>
This is weird
<spacekookie>
Mic92: can you join the link I posted?
<Mic92>
spacekookie I don't get past the echo test.
<Mic92>
Weird
<Mic92>
spacekookie: does for you work all together
<spacekookie>
Can't you just skip that?
evanjs has quit [Ping timeout: 256 seconds]
* spacekookie
sighs at av tech
<niksnut>
maybe we should just do this on IRC :p
<spacekookie>
I think it would be faster at this point xD
<{^_^}>
rfcs#32 (by dezgeg, 1 year ago, open): [RFC 0032] Phase running changes for better nix-shell use
<sphalerite>
make globin the new primary author
<sphalerite>
I think it's been long enough for dezgeg to object :)
<niksnut>
ok let's do it
WilliButz has quit [Remote host closed the connection]
WilliButz has joined #nixos-dev
<niksnut>
how do we actually do that? :-)
<sphalerite>
I'll do it
<sphalerite>
just edit the metadata I'd say
<niksnut>
https://github.com/NixOS/rfcs/pull/55 has been stuck for a while, worldofpeace do you have time to look at it or can we proceed with it? (I think the consensus was to accept it)
<{^_^}>
nix#3549 (by Ma27, 2 weeks ago, open): Merge legacy `fetchGit`-builtin with the generic `fetchTree`-function
<worldofpeace>
sorry, yall for not being present (again) for the RFC meeting without notice. I've been taking a break from #nixos stuff lately. I'll make an exception for RFC-0055 since we're blocked on me and that's not fair. Though there's still other issues with it, mostly the idea of the frequency of how often we do it, who does it, and where it fits in
alp has joined #nixos-dev
<tilpner>
niksnut, Mic92: Two weeks ago I addressed "set an start date", and then claimed I couldn't do much about the other two. That sparked a bikeshed or two in this channel, about whether yearly is the right interval, and whether to attach the process to the release process.
<tilpner>
RFC 55 is a minor improvement, and was barely worth the effort back when I thought it would take a month or two to accept
<tilpner>
I don't currently have time to participate in open-ended discussions that end up in having to re-do parts of the RFC/script, and test it again
<tilpner>
At this point, I no longer care if and how it gets accepted
alp has quit [Ping timeout: 258 seconds]
ssdd has joined #nixos-dev
dongcarl has quit [Ping timeout: 272 seconds]
alp has joined #nixos-dev
<niksnut>
tilpner: understandable
evils has quit [Quit: Lost terminal]
evils has joined #nixos-dev
<Mic92>
tilpner: do you want to close the RFC than?
<gchristensen>
I'd like to see it happen somehow
<gchristensen>
the bikeshed was unfortunate
<Mic92>
gchristensen: there was actually no bikeshedding.
<gchristensen>
oh :)
<Mic92>
gchristensen: the start date is indeed there. That means, we can move it to FCP I guess.
<gchristensen>
there was bike-shedding in this channel as I recall
<cole-h>
^
<cole-h>
I definitely remember that going down in here
<gchristensen>
I believe spawned by me asking that it be attached to the release process to-do list, to make it more likely that it happens regularly
<samueldr>
bikeshed about RFC55 or bikeshed about the RFC process? I think there may be two different discussions
<gchristensen>
about the RFC content, not the process
<Mic92>
gchristensen: this is not mentioned in the RFC thread.
<Mic92>
but makes sense.
<gchristensen>
it wasn't well received, so I never made the comment
<Mic92>
gchristensen: what were the contra arguments?
<LnL>
I think the scheduling question is a valid concern, but not sure that should block the rfc
<gchristensen>
I will try my best to sum it up, and want to say that if I don't get it right, I'm not intentionally misrepresenting the counterargument. ... I believe the concern was that the release process is not at all related to the task, and that adding unrelated tasks to it just because it happens regularly isn't a good idea
<Mic92>
tilpner: sorry, I did not remembered the part that you updated the RFC.
<cole-h>
Mic92: I believe one was that it isn't in any way related to a release
<cole-h>
Yeah
<Mic92>
tilpner: Let's say I volunteer to create the issue to notify people.
<gchristensen>
as an alternative to the release process?
<Mic92>
gchristensen: We just need somebody to run the script and notify people that they are about to be removed as maintainer due to lack of activity.
<gchristensen>
right
<gchristensen>
so how do we make "doing that" part of the systemic, organizational memory of NixOS The Project
<Mic92>
Since it's quite infrequent, I can just put this on my calender.
<Mic92>
gchristensen: we don't have a secretary yet to take care of that, this is another RFC.
<gchristensen>
and that was why I suggested a to-do in the release notes, since that is a fairly guaranteed process to be followed on a regular basis
<Mic92>
I can also create a calendar event and share it other people
<gchristensen>
sure, and the worst case is the program stops being run
<Mic92>
The worst case is that we just deadlock in the RFC process for it.
<andi->
In other communities I'd propose sending an email out to a group address of those maintaining our access to "systems" (GitHub…). Not sure what the canonical way for us would be..
<gchristensen>
heh
<Mic92>
tilpner: Do you want to add a sentence about me beeing the first janitor until further notice to create the issue and going after the NixOS org maintainer to revoke inactive accounts?
<Mic92>
andi-: we already discussed that we use github issues to steer this process.
<andi->
oh
<andi->
I think having that step in the release process would probably not be the worst idea. It at least triggers someone (two people, usually) to poke someone to do that task.
<julm>
TIL, pkgs.nixosTest instead of directly using (import (pkgs.path + /nixos/lib/testing-python.nix)). pkgs.nixosTest takes care of passing pkgs to build-vms.nix, hence preserving overlays and avoiding the reload of nixpkgs for the VM's config.
__monty__ has quit [Quit: leaving]
<abathur>
hopefully this isn't taken as and doesn't turn into a bikeshed... I read parts of the RFC 55 discussion there and here and didn't get a clear sense of why it's a human-handled issue instead of a bot or cron-job thing?
justanotheruser has quit [Ping timeout: 240 seconds]
<cole-h>
I think we still want human handling, especially for something that requires w+ permissions to the org and has the ability to remove people's permissions.
<cole-h>
Could be other reasons, too, but those're the most clear-cut ones to me.
<julm>
roberth++ thanks for nixosTest
<{^_^}>
roberth's karma got increased to 4.00000000000000004