worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS stable: 20.03 ✨ https://discourse.nixos.org/t/nixos-20-03-release/6785 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm | https://logs.nix.samueldr.com/nixos-dev
drakonis has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
das_j has quit [Quit: killed]
ajs124 has quit [Quit: killed]
Scriptkiddi has quit [Quit: killed]
ajs124 has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
orivej has joined #nixos-dev
drakonis has joined #nixos-dev
teto has quit [Ping timeout: 240 seconds]
CRTified has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.8]
alp has joined #nixos-dev
Jackneill has quit [Ping timeout: 260 seconds]
Jackneill has joined #nixos-dev
Jackneill has quit [Max SendQ exceeded]
Jackneill has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
alp has quit [Ping timeout: 265 seconds]
cole-h has quit [Quit: Goodbye]
alp has joined #nixos-dev
FRidh has joined #nixos-dev
__monty__ has joined #nixos-dev
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
lassulus has quit [Ping timeout: 240 seconds]
<domenkozar[m]> clever: what should it be?
<domenkozar[m]> ah I see the gist.
lassulus has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
thefloweringash has quit [Quit: killed]
danielrf[m] has quit [Quit: killed]
vaibhavsagar has quit [Quit: killed]
emily has quit [Quit: killed]
colemickens has quit [Quit: killed]
domenkozar[m] has quit [Quit: killed]
alienpirate5 has quit [Quit: killed]
roberth has quit [Quit: killed]
alexarice[m] has quit [Quit: killed]
Irenes[m] has quit [Quit: killed]
masaeedu[m] has quit [Quit: killed]
nocent has quit [Quit: killed]
bachp has quit [Quit: killed]
rnhmjoj has quit [Quit: killed]
freeman42x[m] has quit [Quit: killed]
arcnmx has quit [Quit: killed]
michaelpj has quit [Quit: killed]
rycee has quit [Quit: killed]
jonge[m] has quit [Quit: killed]
matthewbauer has quit [Quit: killed]
DamienCassou has quit [Quit: killed]
yegortimoshenko has quit [Quit: killed]
worldofpeace has quit [Quit: killed]
bennofs[m] has quit [Quit: killed]
Dandellion has quit [Quit: killed]
mkg20001 has quit [Quit: killed]
dtz has quit [Quit: killed]
jtojnar has quit [Quit: killed]
Ericson2314 has quit [Quit: killed]
timokau[m] has quit [Quit: killed]
PkmX[m] has quit [Quit: killed]
aanderse has quit [Quit: killed]
ma27[m] has quit [Quit: killed]
Ox4A6F has quit [Quit: killed]
abbradar[m] has quit [Quit: killed]
layus[m] has quit [Quit: killed]
pkolloch[m] has quit [Quit: killed]
tokudan[m] has quit [Quit: killed]
Nyanloutre[m] has quit [Quit: killed]
doronbehar has quit [Quit: killed]
justanotheruser has joined #nixos-dev
<arianvp> is it possible to add additional ssh flags to remoteBuilders ?
<arianvp> I need to pass IdentitesOnly=yes to stop the build hook from trying to contact my yubikey
emily has joined #nixos-dev
<srk> arianvp: via .ssh/config
<srk> program.ssh
orivej has joined #nixos-dev
domenkozar[m] has joined #nixos-dev
timokau[m] has joined #nixos-dev
bachp has joined #nixos-dev
michaelpj has joined #nixos-dev
worldofpeace has joined #nixos-dev
jamiemagee has joined #nixos-dev
arcnmx has joined #nixos-dev
Irenes[m] has joined #nixos-dev
Ericson2314 has joined #nixos-dev
bennofs[m] has joined #nixos-dev
DamienCassou has joined #nixos-dev
doronbehar has joined #nixos-dev
rycee has joined #nixos-dev
mkg20001 has joined #nixos-dev
jonge[m] has joined #nixos-dev
abbradar[m] has joined #nixos-dev
nocent has joined #nixos-dev
danielrf[m] has joined #nixos-dev
colemickens has joined #nixos-dev
Ox4A6F has joined #nixos-dev
vaibhavsagar has joined #nixos-dev
yegortimoshenko has joined #nixos-dev
freeman42x[m] has joined #nixos-dev
alienpirate5 has joined #nixos-dev
rnhmjoj has joined #nixos-dev
jtojnar has joined #nixos-dev
dtz has joined #nixos-dev
Dandellion has joined #nixos-dev
tokudan[m] has joined #nixos-dev
thefloweringash has joined #nixos-dev
aanderse has joined #nixos-dev
masaeedu[m] has joined #nixos-dev
matthewbauer has joined #nixos-dev
PkmX[m] has joined #nixos-dev
roberth has joined #nixos-dev
layus[m] has joined #nixos-dev
ma27[m] has joined #nixos-dev
pkolloch[m] has joined #nixos-dev
Nyanloutre[m] has joined #nixos-dev
alexarice[m] has joined #nixos-dev
<{^_^}> nix#1572 (by pikajude, 2 years ago, open): nix no longer tells me why I can't build remotely
<arianvp> thanks domenkozar[m]
<arianvp> that's indeed exactly what I saw
<domenkozar[m]> I went through all nix issues (45 pages, yikes) and tagged all installer bugs with installer label
<Mic92> sphalerite: spacekookie worldofpeace niksnut We have our steering committee meeting today.
<hexa-> Mic92 <3
<hexa-> Mic92 ❤️
<hexa-> owhh cmon
<hexa-> Mic92++
<{^_^}> Mic92's karma got increased to 21
<Taneb> hexa-: I think {^_^} listens for "<3 $username"
<hexa-> yeah, I thought of that as well :3
<hexa-> too late
<Taneb> What is the steering committee? What sort of things does it discuss?
<Taneb> <3 hexa-
<{^_^}> hexa-'s karma got increased to 3
<gchristensen> garbas++ on making those pages
<{^_^}> garbas's karma got decreased to 13
<{^_^}> Wait no, it got *increased* to 15
<lassulus> huh
<qyliss> lol
<xfix> {^_^}: source
<xfix> oh well\
<gchristensen> ,whomademe
<{^_^}> #<prnumber>, ',command' and '> nix' are implemented in infinisil's backend <https://github.com/infinisil/nixbot> utilizing gchristensen {^_^} frontend <https://github.com/grahamc/ircbot/>. The rest of the features are done by other people's backends
tilpner has joined #nixos-dev
<srk> gchristensen: amqp access? :)
<sphalerite> infinisil++ for some excellent easter eggs
<{^_^}> infinisil's karma got increased to 274, it's a crit!
<infinisil> :P
<garbas> is {^_^} gaining conscious? it knows how to make jokes!? :)
<garbas> infinisil++
<{^_^}> infinisil's karma got increased to 275
<srk> :D
<flokli> infinisil: serious feature request: can we get emoji support into {^_^} ?
<flokli> is it utf-16 safe yet?
<infinisil> flokli: Should work already!
<srk> > unicorn
<{^_^}> "🦄"
<flokli> ❤️ infinisil
<flokli> ^ your karma hasn't increased
<gchristensen> ✨ infinisil
<{^_^}> infinisil's karma got increased to 276
<flokli> mmhhh
<flokli> I think I can sparkle to increase karma, hearting should work too.
<infinisil> Ahh, we could add another regex for the emoji heart too :)
<srk> I can't test my bot :(
<infinisil> +1 to srk getting amqp access from gchristensen
<gchristensen> srk: I can get you connected today :)
<srk> \o/ \o/ thanks :)
* srk has some more functionality in progress
v0|d has joined #nixos-dev
NinjaTrappeur has quit [Quit: WeeChat 2.7]
NinjaTrappeur has joined #nixos-dev
<spacekookie> Mic92: the meeting is in 20, right? Just making sure I'm on the right timezone this week x)
<niksnut> yes
<spacekookie> woo
teto has joined #nixos-dev
<spacekookie> I can't seem to see you anymore :(
<Mic92> Me too
<niksnut> people briefly appear and then disappear
<sphalerite> worldofpeace: rfc meeting?
<qyliss> concept: meta.eolDate
<qyliss> We could have a check for disallowing eol software by default, _and_ before a release the RMs could delete anything that would go EOL during the support time of the release
<FRidh> qyliss: Noting eol date is a good idea. But using it for evaluation is impure which I think we should avoid
<qyliss> That's true
<{^_^}> #77434 (by LnL7, 15 weeks ago, open): [WIP] nixpkgs support warnings
<qyliss> Good point.
<LnL> ^ pure evaluation doesn't have builtins.currentTime so as long as that's handled I don't think it's a big problem
<qyliss> You could pass a time as an input to opt in to a check
<qyliss> Would be very cool if, say, you don't plan to update this computer for three months
<qyliss> Pass in the date three months from now
<niksnut> I don't think any use of currentTime is a good idea
<FRidh> yes. For many users that would be good.
<qyliss> But I also don't want to use currentTime
<niksnut> but eolDate is fine
<LnL> what can you do with that without the current time tho?
<niksnut> the RMs can use it to decide whether to remove a package
<qyliss> Pass in a time, use it for release management, etc.
<srk> (that would require some datetime manipulation utils)
<Mic92> spacekookie: are you open the new issue?
<Mic92> for the the meeting?
<sphalerite> niksnut: do you think passing in the current date from nixos-rebuild or similar so that support dates can be checked would be better?
<spacekookie> Mic92: I can open it if you want
<spacekookie> done
<qyliss> I don't think dates should be passed in automatically at all
<qyliss> Because it does introduce an impurity
<qyliss> But I do think there are applications of this where having the metadata is useful
<LnL> needs to be configurable, but not warning people about things that don't get support anymore by default is bad IMHO
<qyliss> Well, that's the status quo :P
<LnL> that said, getting the metadata and using it are 2 different things, the latter is probably less controversial
<qyliss> Using the metadata is less controversial than adding it?
<niksnut> the only "pure" use is if nix itself uses meta.eolDate
<niksnut> e.g. nix-env -i can print a warning
<LnL> I don't really see a difference with populating config.currentTime or something by default
alp has quit [Remote host closed the connection]
<LnL> also package eol is different from nixpkgs eol, etc.
<LnL> qyliss: I mean introducing meta.eolDate for packages but not using it anywhere (by default)
alp has joined #nixos-dev
<Mic92> tilpner: can you address https://github.com/NixOS/rfcs/pull/55#discussion_r384648005 ? Than we can open the FCP.
<Mic92> tilpner: we should not block indefinitly on one member.
<adisbladis> How do I manually start a systemd user session?
<adisbladis> flokli: ^
<flokli> adisbladis: more context please ;-)
<adisbladis> flokli: I'll pm :)
<flokli> ok
orivej has quit [Ping timeout: 246 seconds]
FRidh has quit [Ping timeout: 246 seconds]
FRidh has joined #nixos-dev
orivej has joined #nixos-dev
tdeo has quit [Quit: Quit]
tdeo has joined #nixos-dev
tdeo has joined #nixos-dev
tdeo has quit [Changing host]
drakonis has joined #nixos-dev
<globin_> jtojnar: are you working on a fix for ibus-setup? #85515
<{^_^}> https://github.com/NixOS/nixpkgs/issues/85515 (by worldofpeace, 1 week ago, open): ibus-setup fails to start
globin_ is now known as globin
globin has quit [Changing host]
globin has joined #nixos-dev
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
spacekookie_ has joined #nixos-dev
cole-h has joined #nixos-dev
Profpatsch has quit [Ping timeout: 246 seconds]
spacekookie has quit [Ping timeout: 272 seconds]
Profpatsch has joined #nixos-dev
justanotheruser has quit [Ping timeout: 244 seconds]
<cole-h> MichaelRaskin: re your question on the liberation_ttf_v2 PR -- I think it's because cvc4 depends on jdk, which depends on liberation_ttf, as you noted.
<MichaelRaskin> Ah, that's just me underestimating the rev-deps of JDK. Makes sense, thanks
<cole-h> :)
justanotheruser has joined #nixos-dev
spacekookie_ is now known as spacekookie
kraem has quit [Quit: outta here]
<worldofpeace> globin_: I think the fix is maybe moving it from preFixupPhases to using addEnvHooks
<worldofpeace> * preFixupHooks
<globin> worldofpeace: that was more of a question if i'd be wasting time on it if I start looking at it and jtojnar nearly being finished or if it would actually make sense
<jtojnar> sorry, did not start on that yet
<jtojnar> if someone wants to tackle that, feel free
kraem has joined #nixos-dev
<jtojnar> worldofpeace: yeah, we will have to make it prefixup hook as before
<jtojnar> the main issue is we will now have multiple preFixup hooks depending on each other
<jtojnar> so we will need to force ordering again
<jtojnar> globin^
dongcarl has quit [Read error: Connection reset by peer]
alp has quit [Ping timeout: 246 seconds]
nschoe has joined #nixos-dev
<jtojnar> <3 srk
<{^_^}> srk's karma got increased to -2147483648
<srk> lol
<jtojnar> <3 srk <3 srk <3 srk
<{^_^}> srk's karma got increased to 12
<srk> jtojnar: <3 thanks for the poke, it is quite fun so far and good learning experience :)
<srk> <3 jtojnar
<{^_^}> jtojnar's karma got increased to 46
<jtojnar> now I am thinking about querying the AST with XPath-like expressions
<srk> ;)
<srk> on it already :D
<srk> had to clean this up as it was quite messy earlier today so I can start to generalize the combinators a bit
<Ericson2314> Jan Tojnar worldofpeace: btw https://github.com/NixOS/nixpkgs/pull/31414 was my old attempt at making orderings sane
<{^_^}> #31414 (by Ericson2314, 2 years ago, closed): Stdenv setup: Process dependencies before dependents
<Ericson2314> It might be possible to actually get working with a few tweaks
<LnL> srk: very nice!
<Ericson2314> the trickiness with the *-wrappers was that search paths are left beats right, while regular flags are right beats left
<Ericson2314> I think if we change the wrappers to accumulate the search paths stuff separately
<Ericson2314> it will be much less fragile and then this can land
<srk> LnL: thanks, hope we can merge this together at some point with event stream
<Ericson2314> and then we know the setup hook application order, which makes other things a bit saner
<Ericson2314> like controlling other hook order
<LnL> srk: FYI I already have a POC thing that generates data for broken builds
<srk> cool, I've noticed something related on #nixos-ofborg
<LnL> nothing finished yet, but I could run it to get you a bit of data if you want :)
<srk> LnL: would be nice but no rush :)
<cole-h> srk++ Also would be cool if it didn't require hnix-overlay to build/run... ;)
<{^_^}> srk's karma got increased to 13
<srk> cole-h: that's not that easy but soon-ish :)
<cole-h> srk: Even making a default.nix that imports hnix-overlay would be welcome
<srk> ah right
<cole-h> Just want to keep it all in one place
<cole-h> Improvements can come later :^)
<srk> cole-h: there's meta/ in hnix-overlay prepared for that
<srk> cole-h: I'll add that and the overlay to NUR
<srk> and tests.. but not today :D
nschoe has quit [Remote host closed the connection]
nschoe has joined #nixos-dev
alp has joined #nixos-dev
<jtojnar> Ericson2314: but to know the application order, would not we need to know the whole dependency tree? e.g. if I something with a setup hook deep in the transitive dependencies of first buildInput is propagated, it would run before thing propagated by dependency of a second buildInput?
<jtojnar> I would still want to make sure glib's preFixup runs before gobject-introcpection one's no matter how the dependencies are ordered: https://github.com/NixOS/nixpkgs/blob/9d11b73c332d4ae65ea6dc9aad1c236100f7e4a9/pkgs/development/libraries/glib/setup-hook.sh#L27-L34
orivej has quit [Ping timeout: 246 seconds]
<Ericson2314> Jan Tojnar: yeah it recurs through all dependencies and only once it gets back to the node does it enqueue it's setup hook
<Ericson2314> this is esepcially better because we only process dependencies once
<Ericson2314> maybe the dependency was already processed, but it's fine because it still comes first -- we still get valid topological sort
<Ericson2314> right now we don't get a valid reverse topological sort because while the dependency is processed second if it is new, it is processed first if it is old
<jtojnar> globin: I think I will just fix it, no point of delaying it
<prusnak> can someone add "6.topic: java" label to nixpkgs? or what's the correct process for requesting new labels?
<srk> I was thinking about "package update" label the other day but that would require a bit of automation
<prusnak> there is "8.has: package (update)"
<srk> hmm, so it's just not applied, I see
<srk> good
<srk> (automatically for simple updates I mean)
<prusnak> and it seems that you are right, the label "8.has: package (update)" was always applied manually
<prusnak> "8.has: module (update)" is being added automatically, though
<srk> will take a look at ofborg if it can be added easily
<prusnak> there is already an issue for that: https://github.com/NixOS/ofborg/issues/318
<{^_^}> ofborg#318 (by etu, 1 year ago, open): Feature request: Add label for pull requests that contain package updates
<srk> good, will try to PR something :)
<jtojnar> worldofpeace: globin https://github.com/NixOS/nixpkgs/pull/86416
<{^_^}> #86416 (by jtojnar, 5 minutes ago, open): gobject-introspection: Ensure the giDiscoverSelf is run before gappsWrapperArgsHook
<globin> Ericson2314:^
abathur has quit [Quit: abathur]
<Ericson2314> looking
<Ericson2314> yeah fine for now
abathur has joined #nixos-dev
orivej has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
nschoe has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
alp has quit [Ping timeout: 272 seconds]
<tilpner> Mic92: I'm not sure. I can of course set an arbitrary start date, but it depends on when we get this accepted. And creating the issue and sending a mail is the responsibility of the person enforcing this, who I also can't just choose arbitrarily.
<Mic92> tilpner: I would make it relative to the accepting date.
<tilpner> Mic92: The RFC already states that the process "is repeated at the beginning of each new year". I was hoping that to mean Jan 2020, but that didn't work out
<Mic92> tilpner: You can rephrase it to do one process after accepting the RFC and than in January again.
<tilpner> Mic92: If we want to have a special "catch-up" invocation, sure, we can do that
<Mic92> tilpner: It's not the final word either. There is still an FCP
<tilpner> I intentionally left the part of "who does this" underspecified, hoping that someone with the authority to enforce it would fill in the gaps. I can't really addres that point myself
<Mic92> tilpner: did not we discuss this in the meeting?
<Mic92> My memory is a bit lacking
<tilpner> We touched on it, but AFAIR we didn't settle on a specific person
<tilpner> It's probably going to end up being yet another task for eelco or graham
<Mic92> tilpner: I think at some point we had a list, who was adminstrator. domenkozar[m] was in this list.
<tilpner> Mic92: Pushed a +1/-1 to mention it takes effect after being accepted
<domenkozar[m]> I'm not following :)
drakonis has quit [Read error: Connection reset by peer]
<Mic92> domenkozar[m]: we are talking about who can remove people from the nixpkgs maintainer team. In this case inactive ones.
<tilpner> domenkozar[m]: Do you have the permissions to remove people from nixpkgs-committers? And if so, are you wiling to commit to enforcing a yearly process of removing inactive committers from it?
<Mic92> tilpner: I think we can even set up a calendar even or so.
<Mic92> As a reminder
<Mic92> domenkozar[m]: we are talking about: https://github.com/NixOS/rfcs/pull/55
<{^_^}> rfcs#55 (by tilpner, 28 weeks ago, open): [RFC-0055] Retire inactive nixpkgs committers
<Mic92> tilpner: The person that figures out inactive members and sent out the email does not even have to be an admin. As long as this person instructs one of the admins to remove the inactive accounts.
<Mic92> tilpner: You could even do it.
<gchristensen> tilpner: once the RFC is accepted we don't need any particular admin to commit to enforcing it
<tilpner> Mic92: Maybe. This admin would still have to verify my list, and it adds some overhead.
<gchristensen> verifying a list is easier than making it
<tilpner> gchristensen: Mic92 asked to address the open question of "Who is doing the removal"
<gchristensen> "any admin"? :)
<tilpner> gchristensen: No, it's literally the same step
<gchristensen> okay
<tilpner> Just run the script in the RFC, and see if it agrees with the list I sent
<tilpner> Admittedly, this would save a few minutes of writing the notification issue
<tilpner> gchristensen: "any admin" was the default values, yes. But the concern was that nobody might feel responsible, and it wouldn't happen. Which can be fixed by nagging on IRC
<gchristensen> there is no system in place for "yearly" events
<gchristensen> one substitute could be making it part of the release process, making it 6monthly
<tilpner> It's been so long, I don't care anymore about the specifics
<gchristensen> the 6monthly cron job of "release nixos" is probably a good place to add it
<tilpner> That implies changes to the RFC and the script
<gchristensen> only do it on the .03 release?
drakonis has joined #nixos-dev
<gchristensen> the idea being bake it in to a process which already exists, than count on a particular admin to remember and do it
alp has joined #nixos-dev
<worldofpeace> I don't like the idea of making it a process of release nixos, it has nothing to do with nix & OS, it's about its structure.
<worldofpeace> that just adds overhead to the release where it isn't needed?
<gchristensen> my thinking is add a bullet item "ping an administrator to execute RFC55"
<gchristensen> pretty low effort from the release team, but guaranteed to be seen twice a year
<jtojnar> I have rage written this https://github.com/jtojnar/cmake-snips so I can send it to every CMake project ever
<worldofpeace> I still don't think that makes sense. That is a task for the "NixOS org infrastructure team i.e github admins"
<gchristensen> worldofpeace: so are lots of other thinsg in the release checklist, but there is no "hook" right now to put a yearl thing on to other than that
<worldofpeace> who has write access shouldn't concern the release team.
<gchristensen> anyway, if you don't like it, thatis okay, ignore it -- but I just dont see it happening otherwise
<gchristensen> jtojnar: nice :) though maybe s/fringe//
<worldofpeace> well, what is in the release checklist is something for the team to supervise or delegate. But atm, it should be someone's responsabilities to oversee who gets added to the org, who gets removed, and that would also be RFC55. We create a new team called GitHub Admins, and that's people who already invite people to the org, add a section to the nixos manual about how and when to do it, and then the GitHub admin team is
<worldofpeace> pinged at the same date every year to do it.
<gchristensen> and who pings them?
<worldofpeace> * responsibilities
<worldofpeace> or no one pings them, you just assign a single person in even rotation of the GitHub admin team to just do that for whatever year. and we really could use a nixos.org calendar
<gchristensen> to just remember
<gchristensen> yeah
<gchristensen> I don't understand the distaste to putting it in the release steps to have an admin do this, it seems light-weight, existing, and fault-tolerant
<gchristensen> but okay
<gchristensen> I need to walk away for a while, catch y'all later :)
<worldofpeace> you could create some sort of contraption that creates an automated issue on github and pings the team even. i.e a cronjob yearly
<MichaelRaskin> A yearly cronjob to interact _with GitHub_ sounds like an experiment whether failure rate can beat 100%
<LnL> that's a _really_ hard thing to do correctly and monitor
<cole-h> See: all the recent ofborg-internal-error labels
<MichaelRaskin> We _do_ have a yearly process that happens on the edge of the years, but I am not sure it is a good idea to hang such things there
<worldofpeace> (*throws that in the trash. anyways, you can't trust github to even reliably create an issue.) I've already seen someone get their commit bit back after being removed from not having 2fa. it wasn't hard to get back. to just remember with some sort of calendar reminder, email, has to be fine? 2020 and we can't send email, then maybe we should stop internetting.
<MichaelRaskin> We cannot make a low-notability yearly process. We never could, but we have actually noticed now
<qyliss> We update the copyright notice every year :P
<MichaelRaskin> ± 3 months or so?
<qyliss> Doesn't have to be exact, presumably
<worldofpeace> MichaelRaskin: I don't think I understand what you mean exactly
<MichaelRaskin> Well, I believe that RFC SC rotation is a yearly process that is visible and long and high-profile enough that it will actually happen yearly approximately at the planned time.
<MichaelRaskin> On the other hand, updating copyright notice, or running obsolete-entry-collection on the committer list is like SSL certificate update in the bad old days.
<MichaelRaskin> A small yearly thing that is very often not done on time.
<worldofpeace> so you're saying it needs to be checked in smaller increments that someone hasn't contributed in 1 year?
<MichaelRaskin> That has a better chance of working, yes
<LnL> I think there's a boundary somewhere for things that happen not frequent enough where it's basically impossible to automate
<worldofpeace> and your foundational claim is something that is "low-notability" not done in regularity has a high chance of just not being done at all or on time.
<LnL> so doing it continuously would solve that, otherwise you need something to trigger it like the release steps which we're relatively confidant will be read at least twice a year
<LnL> the steps itself could be automated ofcourse, just not the automatic triggering
janneke has quit [*.net *.split]
Taneb has quit [*.net *.split]
m1cr0man has quit [*.net *.split]
makefu has quit [*.net *.split]
eyJhb has quit [*.net *.split]
lovesegfault has quit [*.net *.split]
dottedmag has quit [*.net *.split]
delroth has quit [*.net *.split]
Taneb has joined #nixos-dev
dottedmag has joined #nixos-dev
eyJhb has joined #nixos-dev
janneke has joined #nixos-dev
dottedmag has joined #nixos-dev
dottedmag has quit [Changing host]
m1cr0man has joined #nixos-dev
janneke has joined #nixos-dev
janneke has quit [Changing host]
makefu has joined #nixos-dev
eyJhb has joined #nixos-dev
eyJhb has quit [Changing host]
delroth has joined #nixos-dev
lovesegfault has joined #nixos-dev
<worldofpeace> I get that now
alp has quit [Ping timeout: 272 seconds]
<worldofpeace> And that it needs to be in a place that could be seen by someone, it's just I disagree with that someone being the release team. Throwing more steps into a process just because someone will read them doesn't seem intentional to me
<worldofpeace> But is adding a GitHub admins team out of scope... I don't know
<LnL> yeah, I have no idea about that part of the release process
<MichaelRaskin> We could try to invent a monthly _something_ that is also suited to hang a few yearly tasks onto
<MichaelRaskin> Then it just needs to make sense as a monthly something
<worldofpeace> monthly bikeshed
<worldofpeace> jk
<worldofpeace> hmm...
<MichaelRaskin> Monthly bikeshed sounds good. That would mean we need to _stop_ bikeshedding at least once a month, right?
<LnL> the officehours come to mind, but that's not exactly very structured at the moment
<worldofpeace> ✨ MichaelRaskin
<{^_^}> MichaelRaskin's karma got increased to 0b100001
<worldofpeace> LnL: we do what know with officehours?
<LnL> of the topics could be to see who would fall off the list in each iteration
<worldofpeace> {^_^}: A & B?
<ma27[m]> niksnut: just in case you have time to, would you mind taking a look at https://github.com/NixOS/nix/pull/3549 ? :)
<{^_^}> nix#3549 (by Ma27, 22 hours ago, open): Add support for `narHash` in `builtins.fetchGit`
alp has joined #nixos-dev
justanotheruser has quit [Ping timeout: 256 seconds]
andi- has quit [Ping timeout: 240 seconds]
andi- has joined #nixos-dev
averell has quit [Quit: .]
averell has joined #nixos-dev
justanotheruser has joined #nixos-dev
ehmry has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
ehmry has joined #nixos-dev
__monty__ has quit [Quit: leaving]