<infinisil>
gchristensen: You know what would be nice: A stream of builds that failed, so that you could try fix those errors
<infinisil>
Most commonly @GrahamcOfBorg just finishes with "No attempt" or "Success", which are boring cases
<MichaelRaskin>
That would mean more PRs, that would mean more evaluator overload. So, evaluation-on-builders has to come first, or something
<MichaelRaskin>
(mostly joking)
<infinisil>
:)
<infinisil>
MichaelRaskin: What is the usual procedure to get merge rights for nixpkgs? I'd like to help with PR's but I can't do much more than leave a review, even when I already verified it
<infinisil>
I feel like there needs to be a whole lot more people merging stuff
<infinisil>
I should probably ask this in #nixos
<MichaelRaskin>
infinisil: you ask ikwildrpepper (IRC)/@rbvermaa (GitHub) or niksnut/@edolstra or I think @domenkozar for commit rights. And convincingly signal understanding that complicated/risky/far-reaching things go via PRs with reasonable time for feedback.
<infinisil>
I see thanks
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-borg
<infinisil>
Not sure if I qualify though :P
<MichaelRaskin>
Based on the PR submissions — probably. Then you are also trying to contribute in other ways, so just yes.
<infinisil>
Heh thx, I should probably just ask
<infinisil>
I'm always a bit worried about doing stupid stuff when you got too much power. But then again it's probably the same for everybody
<MichaelRaskin>
I really hope all the important branches are force-push-protected…
<infinisil>
Indeed..
<MichaelRaskin>
You should be careful, but on the other hand, the risky part is git anyway
<infinisil>
Heh yeah, I just had some trouble with git today
<MichaelRaskin>
If you are unsure about the impact of your changes to code, PR is always is option — just explain why you are not pushing it directly.
<infinisil>
I would never do a change without a PR
<infinisil>
I wish I could only have the right to merge PR's (and only ones that aren't mine)
<MichaelRaskin>
Maybe with ofborg it has becomes a viable position…
<infinisil>
Heh, so completely sidestepping GitHubs permission system
<MichaelRaskin>
No, simple updates by committers _should_ be pushed/merged by committers. Maybe with automated verification, but without second pair of eyes.
<infinisil>
Hmm..
<MichaelRaskin>
We don
<MichaelRaskin>
don't have enough eyes
<MichaelRaskin>
and simple updates are a lot of traffice
<infinisil>
Yeah
<infinisil>
wouldn't that lead into chaos?
<MichaelRaskin>
When Nixpkgs had just migrated from SVN, I — an active proponent of «Subversion-is-still-better-than-this-Git-mess» — tried to do everything via self-merged PRs.
<infinisil>
Today when I git blame something, I can pretty much always find a relevant PR with a discussion
<MichaelRaskin>
I got told not to do that.
<MichaelRaskin>
I think there are still a lot of direct commits
<MichaelRaskin>
Maybe all this PR flow has finally overwhelmed all the committers so the direct commits are not just outright majority
<infinisil>
I really like the idea of always having multiple people look at it, and I think it's worked pretty well
<infinisil>
At this scale
<MichaelRaskin>
It has never worked for Nixpkgs.
<infinisil>
It hasn't?
<MichaelRaskin>
There has been no times when everything went via PRs
<infinisil>
I wish we had some statistics on that, how many commits are from PR's
<infinisil>
I bet it's possible to do that with git
<MichaelRaskin>
Statistics will tell you nothing, because the top-commit-count committer has this spot because of massive Haskell semi-auto-updates.
* infinisil
takes a look at the commit list
* infinisil
realizes it's kinda hard to tell which commits are from a PR
<infinisil>
Unless I'm missing something
<MichaelRaskin>
Not really, if you start playing with full metadata
<MichaelRaskin>
You just enumerate PR-merge commits, and look at the smaller side
<MichaelRaskin>
Yes, not trivial.
<MichaelRaskin>
But I mean, it is Git, if anyone cared about history, why would Git be used,
<infinisil>
What's so bad about it?
<MichaelRaskin>
Git just doesn't care about history.
<MichaelRaskin>
I mean, every VCS that really cares about history stores the original branch of the commit together with the commit.
<MichaelRaskin>
Also: reflog is useful (because otherwise why have it), but you cannot sync it.
<infinisil>
Hmm.. You mean like a new branch should keep a reference to the branch it came from?
<infinisil>
Instead of just a commit?
<MichaelRaskin>
About reflog? Well, if you don't advertise bad practices too hard, reflog is not needed
<MichaelRaskin>
But git is broken enough for reflog to be actually needed, but no you cannot have synchronised destributed reflog
<infinisil>
Hmm I guess I haven't used git long enough to understand your struggles :P
<infinisil>
I almost never use reflog
<MichaelRaskin>
Maybe you haven't used enough other DVCSes
<infinisil>
That could be the case
<infinisil>
I was forced to use svn in university this semester, didn't like it very much..
<MichaelRaskin>
What exactly did you need of the poor thing that you ended up not liking it?
<infinisil>
Mainly because I couldn't work when I didn't have internet connection, and that's a very common occurence for me
<MichaelRaskin>
Yeah, SVK is not well-known enough
<infinisil>
But also the fact that the CLI was just awful to use in comparison to git. I bet I could've spent an hour to make it better, but still. No colors, no paging, slow
<MichaelRaskin>
Hm, we still don't have SVK in nixpkgs (and maybe the upstream is dead now)
<MichaelRaskin>
«slow» is very likely related to «relies on the server»
<infinisil>
Ah, I somehow thought that was a typo before you meant SVN
<infinisil>
I'll check out SVK
<MichaelRaskin>
Hm, dead since 2010
<infinisil>
But its idea can live on forever :)
<MichaelRaskin>
Not really, distributed-first systems are simpler to make useful offline
<infinisil>
distributed-first?
<MichaelRaskin>
SVK relies on SVN which is initially designed around a central server
<infinisil>
Oh i see
<infinisil>
MichaelRaskin: What's your favorite VCS today then?
<MichaelRaskin>
It's complicated
<MichaelRaskin>
I mean, my actual favourite is Monotone, but I cannot recommend it because it is somewhat not alive enough.
<MichaelRaskin>
On the other hand, by now I have doubts if Git internals are not a heap of dead unchangeable code…
<infinisil>
The headline of monotore sure does sound nice
<MichaelRaskin>
Monotone is nice in theory, nice in implementation, but some of the larger nice projects have stalled, and it also seems stuck with SHA1.
<MichaelRaskin>
On the other hand, Git is possibly also stuck with SHA1…
<infinisil>
Monotone claims in their FAQ: "We know how to do the switch [away from SHA1], and it should be straightforward."
<MichaelRaskin>
The horrible part is that I really like some sides of Monotone that no other system shares right now.
<MichaelRaskin>
Yes, I know, but the fact is that there is no plan to actually do it.
<infinisil>
Oh and they use sqlite, interesting
<MichaelRaskin>
Which means that their on-disk consistency is actually a thing that exists.
<infinisil>
Git doesn't have that?
<MichaelRaskin>
Git relies on the detailed knowledge of ext3 (applied by Linus Torvalds) behaviour to be fast and save. Too bad ext3 might have changed some parts of it, and ext4 just never had this behaviour.
<infinisil>
That does indeed not sound very atomic
<infinisil>
I'm gonna give monotone's docs a read today
<MichaelRaskin>
I really like this «a single database to rule them all» because it helps with backups. A lot
<MichaelRaskin>
From the reading-docs point of view I can also recommend Pijul
<infinisil>
That also sounds interesting
<infinisil>
"we wanted none of our algorithms to have a complexity more than O(log h)"
<infinisil>
Oh and written in Rust haha
orivej has joined #nixos-borg
<infinisil>
MichaelRaskin: So, I've read about both monotone and pijul
<MichaelRaskin>
Well, you could be interested in reading about Fossil, too
<infinisil>
I like monoton's database idea and the certificates
<infinisil>
And pijul's way of handling patches is really nice
<infinisil>
Monotone seems more of like a git with more functionality
<MichaelRaskin>
Actually, with less overall functionality, but with actual design
<infinisil>
It has more fundamental concepts
<infinisil>
Not sure if that's a good thing, I wasn't convinced after giving it a read, maybe that changes if I use it though
<MichaelRaskin>
Well, Git has zero concepts or anything
<infinisil>
Well there are commits and references
<MichaelRaskin>
Well, not sure Git has enough coherent design to call anything concepts