<thoughtpolice>
gchristensen: in 8413f22bb39bd1c8adcf2ca9e6fcd4c59ddb3549 you formatted the manual; how do I do that myself?
<thoughtpolice>
Sorry if obvious; I'm merging in some stuff and I wrote a bunch of stuff in the manual that conflicted, and in the end I of course would like to keep it formatted.
<Profpatsch>
roberth: Out of my league, you should wait for aszlig
<roberth>
thanks
orivej has quit [Ping timeout: 244 seconds]
globin has joined #nixos-dev
<ekleog>
domenkozar: I think it at least requires @grahamcofborg merge-after (build foo and test foo)
<ekleog>
because people won't want to have to come back to the PR after ofborg's run
<domenkozar>
what if we turn it around
<domenkozar>
make revert if CI fails?
<domenkozar>
and*
<ekleog>
yeah, that's possible too, but CI would then have to run for each commit sequentially
<ekleog>
also, it's also what we're supposed to already be doing manually with hydra, but in practice I've yet to see someone do the revert… maybe an automated tool doing it would actually help here
<domenkozar>
doing evals per commit is something that eventually would need to be done to determine what broke things
<ekleog>
well, it could also just do like hydra and then bisect the error
<clever>
when i was at ase2017, the google CI system would automatically test commits in a bisect fashion, to figure out where the state changes happened
<ekleog>
btw, rust's enforcing CI to run before merging made them have to rollup PR's that are a merge of multiple PR's and send them all at once to their CI, as it can't rebuild each commit… I think we'd better avoid this pitfall :)
<simpson>
git has bisection too. The main thing we'd need is a standing policy that, generally, committers should work to keep their PRs bisectable.
<clever>
simpson: ive had the fun of bisecting, when 2 different bugs caused the same symptom, and even after fixing one, i have the bisect the same range again
<simpson>
ekleog: They do it that way because Gerrit does it that way, likely. And yes, we should try to avoid it if we can.
<clever>
once both where fixed, i added more CI, so it couldnt go undetected so long again
<simpson>
clever: I *hate* it when that happens. The worst is when working on some messy C project and not all commits can be compiled.
<domenkozar>
you can also have two PRs that evaluate separately but fail once merged :P
<domenkozar>
so doing it in master solves that
<clever>
simpson: oh, and exactly this has happened on nix itself
<ekleog>
domenkozar: In my mind the point of merge-after (build foo and test foo) was that it'd merge after having built foo and tested foo on top of master :)
<ekleog>
(but this will likely be subject to the issue rust has, so doing periodic evals and bisecting would likely be better))
<domenkozar>
I think the overhead is costly
<domenkozar>
for each thing you put in, you go through hoops
<domenkozar>
instead, if you eval after and revert
<domenkozar>
there's no damage, you email the author and say this shoudn't have been in master anyway
<ekleog>
well, this would be required only for release branches anyway afaiu (as they are the only protected ones)
<domenkozar>
that way you trust people by default
<domenkozar>
instead of punish them for testing their PRs :)
<ekleog>
it's basically replacing a click on the “merge” button with a “@grahamcofborg merge-after (build package)”
<ekleog>
but yeah, I agree with you testing on master / release-* and auto-reverting would likely be better
<domenkozar>
yeah but imagine the workflow that folks have now
<domenkozar>
they make a change, commit, tests and git push
<domenkozar>
no github involved
<domenkozar>
so that workflow stays the same with reverts, but changes drastically with github PRs
<ekleog>
in my mind this workflow was only changed for protected branches, for which it's already changed now (but I insist we agree testing on the branch directly is better :P)
<domenkozar>
:D
Synthetica has quit [Quit: Connection closed for inactivity]
<globin>
lopsided98: did you try using callPackages (note the 's')?
<lopsided98>
globin: You mean just replace callPackage with callPackages for gst_all_1 in all-packages.nix? Or is callPackages be able to make 'extend' (or similar) work w/o makeExtensible?
drakonis_ has quit [Ping timeout: 268 seconds]
<globin>
lopsided98: replace callPackage with callPackages, then you can do gst_all_1.gst-plugins-bad.overrideAttrs and AFAIU all should work. But may be that I'm not aware of some edge case or some other issue
<lopsided98>
How would that work in an overlay, where I want the overridden package to automatically be used by anything that depends on it?
<lopsided98>
I'm also not sure how to do the libav = ffmpeg override with callPackages
orivej has joined #nixos-dev
<lopsided98>
I also don't see how to automatically fill in derivation function arguments that refer to other packages in the attrset w/o newScope