<manveru>
is there a convenient way to do `nix repl .` for flakes yet? atm i have to type 'x = getFlake (toString ./.)'` everytime...
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
mmlb3 has quit [Quit: Ping timeout (120 seconds)]
orivej_ has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-dev
<Ericson2314>
When is somebody going to separate the display manager stuff from xserver?
<samueldr>
Ericson2314: sounds like you're a volunteer :)
<Ericson2314>
colemickens: or, how do you use your nixpkgs-wayland?
<Ericson2314>
n-n-n-n-n-n-
<Ericson2314>
I have too many yak shaves as it is
<colemickens>
Pre-HM: `programs.sway.enable`.
<colemickens>
Post-HM: that (for the PAM bit it includes) + the relevant HM bits activaetd/configured.
orivej has quit [Ping timeout: 240 seconds]
<colemickens>
I haven't gotten fancy and tried to run sway as a systemd user unit or anything, I think the HM module supports it. (redshift runs via HM as a user unit) (swaylock is launched by sway).
<colemickens>
and then I just login to tty and type `sway`.
orivej has joined #nixos-dev
<Ericson2314>
does your thing ahve the redshift patch then?
<Ericson2314>
I put on yellow glasses over r egular glasses as stop gap :)
<colemickens>
I don't know the intracacies of DMs. I do know that I have successfully launched Sway from ... GDM? maybe? and noticed that it actually seemed to fix a couple GTK related things.
<matthewbauer>
So ideally we could run all DMs under wayland and simplify things a bunch. But IIRC nvidia still has issues with wayland environments. Is that expected to change any time soon?
<matthewbauer>
If we have to support both wayland & x11, we might as well make a new module just for wayland "login managers" like sddm, lightdm, and gdm and make that opt-in
<matthewbauer>
that would avoid breaking most users x11 configs
<matthewbauer>
It looks to me like the display-manager module is very tightly coupled to x11
<matthewbauer>
There's other legacy reasons why users might want x11 (virtualbox has bad wayland integration iirc)
<Ericson2314>
yeah that sounds good to me
<Ericson2314>
it can be clean slate until it's mature enough to make the big unification worth it
<gchristensen>
I'd like that. I'm afraid of how many peolpe aren't safely starting sway
<colemickens>
what does that mean though? Does that imply that `programs.sway.enable` is insufficient? Just those using it without the module? Does a DM add an extra layer of security not present otherwise?
<colemickens>
(I'm unsure on how deep my ignorance is around this topic)
<gchristensen>
correct, it isn't sufficient
<colemickens>
Do we have an issue open for that?
<gchristensen>
running sway yourself, you have to protect yourself against sway crashing and leaving an unprotected logged in tty. display managers protect against this
<colemickens>
aha
orivej has quit [Ping timeout: 256 seconds]
<JJJollyjim>
if i were sway, i would simply not crash
justanotheruser has quit [Ping timeout: 260 seconds]
drakonis has quit [Quit: WeeChat 2.8]
drakonis has joined #nixos-dev
justanotheruser has joined #nixos-dev
<emily>
02:54 <gchristensen> running sway yourself, you have to protect yourself against sway crashing and leaving an unprotected logged in tty. display managers protect against this
<emily>
isn't the fix here as simple as "exec sway"?
<emily>
not that having to remember to do that is great, but I don't think you need a full DM
<cole-h>
Correct, `exec sway` does alleviate the issue.
<cole-h>
(I won't say it /solves/ it because that's a mighty bold claim for something I know next to nothing about)
<colemickens>
I was wondering if 'sway; exit' was sufficient...
drakonis has quit [Read error: Connection reset by peer]
<doronbehar>
Quick question: are `passthru.updateScript` being run for unfree packages?
<MichaelRaskin>
I am not sure it is autorun for anything
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #nixos-dev
<JJJollyjim>
hmm
<JJJollyjim>
oh wrong channel
mkaito has joined #nixos-dev
puck has quit [Quit: nya]
puck has joined #nixos-dev
orivej has joined #nixos-dev
orivej_ has quit [Ping timeout: 256 seconds]
teto has joined #nixos-dev
<gchristensen>
emily yes
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
teto has quit [Ping timeout: 260 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
alp has quit [Ping timeout: 246 seconds]
teto has joined #nixos-dev
alp has joined #nixos-dev
teto has quit [Ping timeout: 272 seconds]
__monty__ has quit [Quit: leaving]
<manveru>
gchristensen: i'm just in love how clean flakes look/feel/work :)
<gchristensen>
awesome :D
orivej_ has quit [Read error: Connection reset by peer]
orivej has joined #nixos-dev
* adisbladis
is still very confused by flakes
<JJJollyjim>
❄️
<manveru>
i think i'll have to write some post about the hidden features...
<manveru>
but i guess since it's not released yet, niksnut doesn't want too many users depending on current behavior :|
<gchristensen>
truth
<manveru>
it's just a bit weird, because it's already pretty awesome and i'd like more people to give it a try so we find more issues earlier and the world's a better place :)
<gchristensen>
manveru++ I need to give it a go :)
<{^_^}>
manveru's karma got increased to 39
<srhb>
manveru: There is a PR open from flakes -> master, so maybe soon.
<JJJollyjim>
I've seen some suggestions that flakes will somehow improve evaluation performance
<JJJollyjim>
What's the idea behind that?
<manveru>
it can cache evaluation
<manveru>
because it doesn't allow impurity like `builtins.currentTime` or `builtins.getEnv`
<manveru>
that's my nixos-rebuild timing with flake :)
<Profpatsch>
counting down the seconds until people suggest splitting nixpkgs in very many tiny repos
<Profpatsch>
because that’s how you make it fast
<manveru>
well, i split out the nixpkgs lib into a flake yesterday...
<Profpatsch>
this spells disaster
<manveru>
because i don't want to download 16MB everytime i need to use a lib function...
<Profpatsch>
dynamic linking all over again
<JJJollyjim>
What does it mean to cache the evaluation of nixpkgs, if I'm not evaluating the whole thing?
<JJJollyjim>
Does it just cache everything that's been done so far, and add to it later?
<JJJollyjim>
(i'd love to have enough ram to eval the whole thing but I don't think that's happening :P)
<JJJollyjim>
But yeah that's pretty cool in either case
<manveru>
not sure about that
teto has joined #nixos-dev
<manveru>
Profpatsch: i can't imagine nixpkgs becoming much smaller because of flakes anytime soon
<manveru>
but it will lead to more distributed packaging
<manveru>
so it won't grow at such a crazy pace anymore
<adisbladis>
I hope that won't be the case
<adisbladis>
Monorepos <3
<manveru>
i'm already managing projects that pull from 6+ different nixpkgs versions using `niv`...
<adisbladis>
I think it's a key factor to he success of Nix
<manveru>
agreed
<manveru>
i just don't think wishful thinking will help in this case :P
<JJJollyjim>
it'd be nice to get the performance benefits without dropping the monorepo
<JJJollyjim>
if nixpkgs can become several flakes, or something
<Profpatsch>
manveru: pretty sure your problem isn’t going to go away if nixpkgs is split up.
<Profpatsch>
In fact, I’d wager it’s going to increase, but you won’t notice at first
<manveru>
Profpatsch: i'm aware of that
<Profpatsch>
But then the complexity goes up exponentially, and it surpasses the monorepo complexity by far
<manveru>
i'm not saying this is good or bad, just what is likely to happen anyway
<manveru>
and probably there will be some effort to combine popular flakes into nixpkgs
<manveru>
and using the input flakes input overrides, you can reduce the number of nixpkgs versions involved
<manveru>
without upstream having to change it themselves
<manveru>
but it's still gonna involve lots of politics i guess :P
<Profpatsch>
The main reason nixpkgs grows so fast is that it’s standardized. If we split it up, the flakes are going to diverge and the overhead is going to grow and grow
<manveru>
who is "we"?
<Profpatsch>
e.g. some people will want to have a different stdenv
<Profpatsch>
Or replace callPackage
<Profpatsch>
Or do overrides differently
<Profpatsch>
And stuff like staticPkgs won’t be viable, it only works because everything in nixpkgs works roughly the same
<Profpatsch>
So we lose all of that
<manveru>
yeah
<Ericson2314>
what's the best way to nuke a ref from lib to dev
<Profpatsch>
Not to mention ofborg, r-ryantm, you name it
<Ericson2314>
I garther nuke-refs is to much.....of a nuke
<Ericson2314>
*gather
<Profpatsch>
Ericson2314: remove-references-to
<Ericson2314>
thanks
* Ericson2314
feels rusty
* Profpatsch
had to look it up, even though he used it recently
<manveru>
Profpatsch: i'm well aware of that, and would be pretty devastated if this is the case as well... :(
<manveru>
that's why i would like to discuss these things and make some guidelines before it's too late
<manveru>
and why i don't advertise flakes publicly yet, or use them for anything but toy stuff
<manveru>
but the social independence from nixpkgs will most likely lead to NUR^10
<JJJollyjim>
as a fairly new nix user, the social barrier to contributing to nixpkgs is less than anything comparable imo
<JJJollyjim>
(i.e. other linux distros....)
<manveru>
for you maybe :)
<Ericson2314>
Profpatsch: agreed, we must not split nixpkgs
orivej has quit [Quit: No Ping reply in 180 seconds.]
<Ericson2314>
the point of nixpkgs is to integrate disparate things. It is supposed to be big and monolithic
<manveru>
JJJollyjim: it's still a higher barrier than a git push to your personal repo
<Ericson2314>
if something should be split out, well that's what repos for upstream packages are far
<JJJollyjim>
manveru: for sure
<JJJollyjim>
but try updating a package in debian
<JJJollyjim>
try reporting a bug to debian
<manveru>
so let's say firefox adds a flake.nix to their repo, how would nixpkgs respond?
<JJJollyjim>
you need to like send an email with netcat to set the right headers
orivej has joined #nixos-dev
<manveru>
would you: a) add it as input to nixpkgs and let them maintain their own things; b) copy the flake somehow; c) rewrite it in current style?
<JJJollyjim>
is this different to how nixpkgs-mozilla is currently handled?
<niksnut>
would nixpkgs need to respond?
<manveru>
and for something that doesn't have a drv in nixpkgs yet and is reasonably complex, i think the answer will be (a)
<niksnut>
it's up to users to use the firefox flake
<manveru>
niksnut: and that's what Profpatsch and Ericson2314 want to avoid :)
<manveru>
i'm just trying to say that people are too lazy to avoid it
<niksnut>
of course, with something like firefox, you do want a binary cache and that's tricky with flakes
<Ericson2314>
falkes could maybe be used to split out nixpkgs lib
<Ericson2314>
but for upstream pacakges, the current culture of distro and upstream dev collaboration is pretty bad
<manveru>
and we might end up in more of an npm situation than an AUR one, and most definitely not a monorepo...
<Ericson2314>
so I assume unless there is a huge sift in that culture any upstream-made flake would also be hard to integrate
<Ericson2314>
yeah nur + nixpkgs + lib + nixos as flakes is probably OK
<Ericson2314>
but don't really see the benefit
<manveru>
the point of a flake is that you don't have to integrate it?
<Ericson2314>
when things can evolve independently, multiple repos is nice
<manveru>
it is self-contained for the most part
<Ericson2314>
if things that exist out of nixpkgs use flakes that's fine
<manveru>
niksnut: i think your blender example shows this nicely
<Ericson2314>
"self-containined" is kind of a lie in general
<Ericson2314>
everything depends on something else
<JJJollyjim>
if i were a software i would simply have no dependencies
<Ericson2314>
say something uses blender as a library? Say somebody wants to do a cross-cutting modification of .desktop files or XDG things ro whateer
<srhb>
fwiw one nice thing about flakes that's independent of the worries about losing the monorepo greatness, is that we can finally bootstrap nixpkgs and nixos in a saner way, using only Nix as a dependency. I would love for us to use only that and keep our lovely monorepo.
<srhb>
(Even if it's still a bit troublesome, but that's mostly nixpkgs/flake.nix being a bit unwieldly wrt. overlays and such, nothing fundamental)
<Ericson2314>
srhb: I am interesting wat you have in mind. Certainly I agree pro-monorepo doesn't mean anti-flake
<Ericson2314>
*intersested what
* Ericson2314
types poorly already, and then riot lag makes it worse
<srhb>
Basically that. :) I do worry that there will be a cultural switch and my inner doomsday prophet foresees maintaining blackbox repos of random hashes that have no semantic meaning, but I hope we just don't do that.
<Ericson2314>
**interested in what
<michaelpj>
nixpkgs does an incredibly important piece of work in that it defines a *consistent* (fsvo "consistent") slice across the vast quantity of packages. If you don't have nixpkgs, who is running tests to check that updating glibc doesn't break firefox? you push a lot of integration work out into the many, many combinations of flakes that people can use, and in practice I expect that this will lead to more stuff being broken
<michaelpj>
more often
<Ericson2314>
+1
<srhb>
michaelpj: Strictly speaking flakes do not make that impossible. All you need is a flakeref to still do that.
<Ericson2314>
the word "monorepo" to me implies like the whole animal, but nixpkgs feels more like the skeleton: certainly you can modularize with organs, but there's little use splitting the musculoskeletal system!
<michaelpj>
sure, you can have "meta-nixpkgs" that packages together all the flakes - but then you've just remade nixpkgs but more awkward to work with. (this is pretty opinionated, I admit :) )
<Ericson2314>
srhb: it would seem then in the limit there is 1 flake for every ad-hoc package, along with 1 per each language based ecosystem where everything is generated at once?
<clever>
Ericson2314: i tend to use .newScope on most of my projects, to create a self-contained set of packages, that can still accept overlays
<Ericson2314>
that's a lot of flakes
<srhb>
michaelpj: That is what I tried to say before, so I agree with that worry. Just trying not to misrepresent it. :)
<srhb>
Ericson2314: Yeah, it would be.
<srhb>
People might be smart ideas though. All we get is more opportunities. We just have to not build a big footgun from them. :P
<Ericson2314>
clever: Yes things that use newscope could be one flake instead of 1 per derivation, when the "scope" packaages are all the work of collaborating devs or soemthing
<srhb>
Like, I imagine crazy wild stuff like pulling in a build system for a package in reverse. Maintaining it in nixpkgs, where it can easily integrate with all other packages' needs, instead of in my vacuum of a package somewhere on github.
<srhb>
What might things like that change, for instance.
<clever>
Ericson2314: but my rpi-open-firmware stuff isnt using newscope, because i wanted it to benefit from pkgs.pkgsCross
<clever>
Ericson2314: so thats currently an overlay, though, i could maybe make it an overlay that calls newScope...
<clever>
then mapAttrs to rip a sub-tree out of pkgsCross...
<Ericson2314>
clever: oh were you responding to the flakes talk or just brining up someting differerence?
<Ericson2314>
newscope is screwed over by splicing
<clever>
a bit of both, ive not had a chance to really look into flakes yet
<Ericson2314>
splicing must go!
<Profpatsch>
michaelpj: it’s not opinioated, it’s just a fact
<Ericson2314>
I am quite afraid post flakes somebody will try ripping things apart, and it will do irrepairable damage to the community
<Profpatsch>
Every additional git clone is a hard border for somebody who wants to change something.
<Profpatsch>
If you introduce them, shame.
<Profpatsch>
(on you, and in general)
<Ericson2314>
it's hard to corall this many people working on one thing
<manveru>
nixpkgs is the way it is because most upstream packages would never consider adding a nix file to their repo, so adding the drv to nixpkgs is the most efficient for users, right? they get hydra, some testing, collaborated reviews and fixes for free!
<manveru>
also, even if upstream adds nix files, it would still be impossible to reference them in nixpkgs anyway
<Ericson2314>
I am not sure how to recorall everyone if they drift apart witha split nixpkgs
<q3k>
with flakes i'm mostly scared that nixpkgs is then commiting to an API contract between it and all flakes
<Ericson2314>
manveru: srhb : I totally agree that if upstream proojects start using nix as a build system, that really changes things
<q3k>
and once that's there, it's basically impossible to change/fix
<srhb>
Ericson2314: Bear in mind I'd want to keep the build in nixpkgs. Again, because integration.
<q3k>
because you can't make a sweeping change across all users in lockstep, as flakes are no longer under your control
<michaelpj>
yeah, doing flakes properly seems to me to need proper versioning for chunks of Nix code. If nixpkgs is Stackage, we're trying to make Hackage... but without version solving :/
<Ericson2314>
srhb: sorry I must have misunderstood the "package in reverse" bit
<Ericson2314>
Exacty, we need version solving
<Ericson2314>
and we need private vs public deps
<Ericson2314>
and to do that right (better than hackage which is not good enough) we need types, and module types, and verifiable compatability relation
<Ericson2314>
and all this other tooling that nobody is talking about
<Profpatsch>
michaelpj: You can look into the first few comments on the flakes RFC, that’s exactly my review.
<Ericson2314>
Once Cargo or Cabal or something get's this right, then we can talk
<Ericson2314>
you need really good notions of motonicity to have an independently version package ecosystem
<Ericson2314>
it's just the math
<Ericson2314>
there's no escape
<manveru>
nobody's working on that though?
<michaelpj>
Profpatsch: I said something agreeing with you a few commments down ;) we're just rehashing our gripes, it seems
<Profpatsch>
Also what Ericson2314
<Profpatsch>
says, it’s hard math
<Profpatsch>
I’d like to see a few papers on this first tbh
<Ericson2314>
we're asking devs to do CRDTs by hand
<Ericson2314>
and we can't even bother to get computers to do it in most places
<Profpatsch>
And have the implementation be based on previous research
<Ericson2314>
and computers are lot more subserviant
<cole-h>
Step 3 has a nix-env invocation that installs nixos-generate-config and friends
<drakonis>
there it is
<gchristensen>
gnarly, cool :)
<drakonis>
its how i did my migration from a existing distro to nixos
<ajs124>
you can also kexec into a nixos running in ram from most existing distros via something like https://github.com/dasJ/emergency-kexec and install from there
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-dev
orivej_ has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
kloenk has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-dev
ris has joined #nixos-dev
alp has quit [Ping timeout: 258 seconds]
<julm>
excellent 8)
<julm>
das_j++
<{^_^}>
das_j's karma got increased to 3
<gchristensen>
tragically kexec isn't workable here
ris has quit [Remote host closed the connection]
alp has joined #nixos-dev
<julm>
good to know those pkgs.nukeReferences and builtins.unsafeDiscardStringContext used in kexec.nix
orivej_ has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
b42 has quit [Ping timeout: 260 seconds]
b42 has joined #nixos-dev
teto has quit [Ping timeout: 260 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
teto has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
<das_j>
julm: Tbh, I have no idea what they do. As the readme states, I stole that from clever :D
<das_j>
well I do know what they do, but I don't know why
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
<clever>
das_j: without unsafeDiscardStringContext, the kexec script (which contains the path to a full nixos build) will depend on that full nixos build
<clever>
das_j: but a copy of that is already in the initrd, so that causes the kexec_tarball to have 2 full copies of nixos, one compressed and one not
<das_j>
clever: So unsafeDiscardStringContext just drops all dependencies?
<clever>
das_j: yeah
<clever>
it drops them at the build-time layer, so they wont even be in the sandbox when building
<colemickens>
could the index itself be a derivation output with the channel as an input? So a user with custom nixpkgs would need to build the index, but if the user was on a channel, when they `nix-build` it would be a cache hit and seamless download?
<colemickens>
(or is that obvious and unhelpful?)
<gchristensen>
i like that idea colemickens
<gchristensen>
something to think about: the editorconfig check puts a big green check next to a commit, and hides the list of checks which passed. if ofborg is down or behind, it islikely people will think ofborg has approved the PR before it did.
<gchristensen>
this could cause, well, all the problems ofborg is there to prevent. anybody have ideas on ways to deal with this? one way i'd like to is require PRs for all changes which would let us require ofborg's +1
<cole-h>
"require PRs for all changes" -> no more pushing directly to master?
<gchristensen>
right
<LnL>
I think that's one implication of this yes
<LnL>
gchristensen: do you have access to configure that
<cole-h>
Personally a big fan of that alone... But what happens when a branch is failing to eval for one reason or another? Wouldn't that require an admin to step in for merging?
<gchristensen>
LnL: I do
<gchristensen>
cole-h: it would, or making ofborg continue with the check and report the branch fixes the issue
<LnL>
if so does github give you the option to require specific ofborg checks or is that a thing only for the github stuff?
<colemickens>
gchristensen: you can "Require status checks to pass before merging" and I think you can select a specific job to always be requried
<gchristensen>
yeah, I can require a specific check
<cole-h>
But does GitHub know about our various ofborg checks?
<gchristensen>
yes
<LnL>
ok great that would work then
<cole-h>
Oh great.
<qyliss>
We currently get about 10 commits pushed straight to master a day
<cole-h>
However it would be nice to hold off on that until we s/grahamcofborg-/ofborg-/...
<qyliss>
Kernel updates, for a start
<cole-h>
(for the status checks, at least)
<gchristensen>
qyliss: I feel okay with that, and I know there is some discomfort with it
<colemickens>
would those people still people able to self merge? is there `hub` invocation that could auto-open and auto-merge their own PR? could minimize that friction at least.
<LnL>
don't think master is a huge deal, I think the releases might be more annoying
<gchristensen>
colemickens: absolutely
<samueldr>
it will break the most common backports workflow if applied to stable branches too
<gchristensen>
we could apply this only to master and staging
<qyliss>
What would the benefit even be in that case? I imagine most users are on releases
<LnL>
yeah but then it doesn't really solve the status issue :/
<samueldr>
this is something I like from Phabricator, AFAICT you can review changes before or after they are integrated into the main branches
<gchristensen>
release-* branches see much less activity, and mostly backports, and so just in terms of numbers less likely to get broken
<gchristensen>
but I'm also okay saying backports need to go to PRs too
<samueldr>
so a push event can be reviewed post-facto with a tangible thing people can interact with
<samueldr>
it doesn't not-break on push, but it probably makes it easier to track breakage if you can run the CI workflow on that
<qyliss>
You can run CI on direct pushes
<gchristensen>
overall, it doesn't feel unreasonable to say your commits have to pass the checks. I know there are long-timers (and newer!) who have specific workflows they've followed for 15 years (and much less!) but still it doesn't feel unreasonable to say we're at a point where it makes sense
<LnL>
for master I definitively agree
<puck>
requiring every change to go through a PR doesn't explicitly stop evaluation failures on the target branch, right?
<gchristensen>
it is possible that a PR with green checks fails evaluation after merging, sure. in particular for older PRs which are already checked
<puck>
like, running all checks on the branch directly either way seems very much worth it
<colemickens>
heh "Require branches to be up to date before merging" and watch things explode
<gchristensen>
puck: I think I understand what you mean, but I'm not 100% certain. can you say that again a bit differently?
<puck>
gchristensen: the ofborg eval checks should still be run on any commits on branches
<gchristensen>
yep, definitely
<gchristensen>
colemickens: woof
<gchristensen>
the conceret problem here is this green check appears very early and is misleading, and there is no poka yoke to help people do the right thing
<gchristensen>
btw making the eval checks mandatory makes it possible for build failures to become red X's
<cole-h>
What about unsupported platforms -- would those still count as a failure?
<gchristensen>
do they now?
<qyliss>
They're neutral
<cole-h>
Well, they show up as a "neutral" result
<cole-h>
So do actually-failing builds
<gchristensen>
at any rate, it can be made that an unsupported platform isstill neutral
<gchristensen>
qyliss: I'm getting a feeling that you're like, soft-downvote on it. is that about right?
<cole-h>
So I equated the two -- happy to be proven wrong.
<edef>
i'm not necessarily convinced that GitHub PRs should be the sole way things can hit master
<edef>
yes, anyone pushing to master is expected to have run CI over those commits
<edef>
but i am okay with delegating a certain level of trust to committers
<edef>
so consider me a downvote
<qyliss>
It would be cool if we had some pre-made git hook for committers to run before pushing
<samueldr>
the question might sound like it lackes genuine honesty, but is it more about forcing a process through *github*, rather than forcing a CI process to happen for changes to hit master, that is the issue?
<gchristensen>
no, to me github isn't really a thing at all, other than a vehicle
<edef>
github is definitely one of the factors driving my reduced interest in upstreaming the patches in my own tree
<samueldr>
(that was written and posted before I read "yes, anyone [...]")
<gchristensen>
like I said the concrete problem is that for as long as ofborg has been a thing a green check means good to go, and now a green check does not mean thatanymore.
<colemickens>
as a contributor, I have been surprised to look for closed PRs, not find one, open my editor and find that the file I'm editting was touched by a commit. I realize when typing it that maybe I've overly reliant on GH, but it sort of is a weird reminder that I'm in a different tier of contributor that certain others
<gchristensen>
if I could say "require all PRs to have this check pass" I'm all in on that, but it doesn't exist -- I can only turn that on for all activity on the branch
<qyliss>
that's an annoying limitation
<edef>
gchristensen: that's a point against github for me, not one in favour
<gchristensen>
aye, but I'm not really talking about that right now :')
<gchristensen>
(it is a point against in my book too)
<edef>
mm
<edef>
so far i've felt like github coupling and github-induced annoyances and those bothered by them weren't really of any concern to those with wheel bits
<edef>
maybe i'm wrong there, but i've definitely felt like the window of opportunity for improving that situation or even demonstrating alternatives has been closing
<abathur>
gchristensen: just gotta make a corrupt revert-bot that reverts commits that don't pass after the fact and holds them ransom for crypto-bribes
<gchristensen>
abathur: what makes you think that?
justanotheruser has quit [Ping timeout: 260 seconds]
<abathur>
I kid
orivej has quit [Ping timeout: 256 seconds]
<gchristensen>
oops
<gchristensen>
that was for you. edef. edef: what makes you think that?
orivej has joined #nixos-dev
<edef>
colemickens: the process for getting commit bits has been less than transparent in the past, but there is a documented process these days
<edef>
gchristensen: idk, we've sat down and talked about this in person and the impression i got was that it was considered an immutable given at this point
<edef>
gchristensen: sort of independent of its relative merit
<gchristensen>
but what makes the window of opportunity to be closing?
<edef>
any alternative way of providing contributions becomes second-class if GitHub PRs are the sole permitted mechanism
<gchristensen>
ah, I understand
<edef>
even if that path applies all the same checks
<gchristensen>
I wonder if there is a way to set that up
<abathur>
It seems like this has more to do with git than github? Apart from "trust everyone to always remember to run the checks", is there any workflow (anywhere) that _ensures_ checks get run before code lands in master without restricting commit access and bolting on some more rigid workflow?
<gchristensen>
yes, ticking the "Require this check before it lands in master"
<puck>
gchristensen: this requires you to either use PRs or push the commits to another branch first, correct?
<gchristensen>
yeah
<gchristensen>
so that alternative branch could be a method, have it auto-merge to master every time ofborg finishes checking it
<puck>
again, this could still cause failures on master, obvs
<puck>
and also this is already a bunch more rigid
<gchristensen>
yeah but a rare race condition there causing master failures isn't really what I'm worried about :)
<qyliss>
that sounds pretty good to me fwiw
<samueldr>
is there a thing, maybe gerrit is that? that can receive pushes as if it was a git repo, but actually passes them through the CI and only actually pushes once the CI is done and successful?
<gchristensen>
oh cool
<qyliss>
(especially if it ff-ed if possible to keep the history clean)
<gchristensen>
qyliss: I'm glad to hear that
<samueldr>
ah, that alternative branch also seems a good solution that's kinda like it, but not it
<colemickens>
like a master-staging almost
<qyliss>
yeah
<gchristensen>
qyliss: maybe you have some opinions about how you'd want that to work, and could write them down?
justanotheruser has joined #nixos-dev
<qyliss>
gchristensen: I don't think I can. I am _extremely_ burnt out on Nix stuff at the moment.
<gchristensen>
cool, I'll try and write something and share it with you to read, or still too much for now?
<qyliss>
yeah that's probably fine
<gchristensen>
cool. I'm incredibly swamped right now. I will try to put something together unless someone else could take on writing down how this would work :)
<MichaelRaskin>
Hmmmm, I wonder if this ends up with multiple Nixpkgs repos under NixOS organisation with different policies and auto-merge once certain conditions are met
<gchristensen>
ouch
<MichaelRaskin>
Well, GitHub lacks a real tracker for anything
<colemickens>
I am having a really hard time expressing this well, maybe because it's a bit illogical, but having commits without matching PRs feels oddly untransparent to me. Something about nixpkgs, the monorepo, the patchability of everything... makes it feel a bit egalitarian or hyper accessible which is part of what I love. Seeing some skip the public process entirely, feels counter to that? It's not even a permissions, or code
<colemickens>
quality thing. I feel silly explaining it though, so...
<MichaelRaskin>
(like, issues are a random mess, PRs require heroic effort, etc.)
<colemickens>
For example, if I follow nixpkgs mostly via issues/prs, I can miss changes that go straight to git.
<MichaelRaskin>
(I remember being subscribed to the full commit email list… old SVN times…)
<MichaelRaskin>
So having PRs with vastly different lifecycles and processes in different trackers might be actually less mess than we have now
<qyliss>
colemickens: I'm running right now a thing that lists commits that didn't go via PRs
<qyliss>
It's very useful
<qyliss>
I would like to make it public but it needs some improvement
<qyliss>
I think having visibility on direct pushes is important
<qyliss>
and we don't really have that at the moment, but we could!
<gchristensen>
colemickens: there is a somewhat unspoken subtext to this conversation around morals and depending on Microsoft/GitHub/non-foss software for a foss project. a perspective I deeply appreciate every time I can't fix an annoyance or problem, but also appreciate on the moral level.
<qyliss>
unfortunately, as I mentioned already, burnout
<gchristensen>
in my mind I try to balance this part of the problem with the benefits we get from being on github
<MichaelRaskin>
I think by now there is only one benefit — not having to assign ongoing work to keeping the repo up.
<LnL>
gchristensen: thought, a branch where stuff goes before it's tested has a lot of conceptual overlap with staging
<gchristensen>
some people hold their nose and contribute in ways they feel okay about (thank you) and upsetting that workflow is upsetting on more than just a "but my control-key-heater workflow" level
<colemickens>
Aha, see, I sympathize with that fully. I would like to think that "everyone uses the same process [which happens to be GH]" could happen without further entrenching ourselves in GH, but I also know the reality of momentum and costs of moving.
<qyliss>
gchristensen: that's a very good way of putting it
<colemickens>
Hm, good food for thought though. I am considering cases where I have opted not to participate because of technology choices I disagree with.
<qyliss>
it can be difficult to put that into words sometimes
<gchristensen>
qyliss: I'm glad :)
<MichaelRaskin>
Re: different policies — sooner or later we will have some way for any maintainer to merge doc-contents-only commits.
<MichaelRaskin>
Well, I guess getting to some universally understood structure of Nixpkgs manual will have to happen first…
<gchristensen>
for me, I don't really like github , and dont particularly care for its brand of kool aid. and, personally, I think a move away from github would be very costly in a lot of ways