 | Lix Development | 346 Members |
| (Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel. | 125 Servers |
| Lix Development | 346 Members |
| (Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel. | 125 Servers |
| Sender | Message | Time |
|---|---|---|
| 24 Apr 2025 | ||
 hexa | that is TCP | 00:15:32 |
| hexa | they probably announced 0-RTT | 00:16:12 |
| hexa | https://blog.cloudflare.com/introducing-0-rtt/ | 00:16:16 |
| hexa | pretty much 10 years ago 😄 | 00:16:23 |
 Irenes | no, no, I know about TCP lol | 00:17:57 |
| Irenes | this was a cryptographic handshake | 00:18:01 |
| Irenes | I think it was something about where certificates are held being different from where TLS is terminated | 00:18:37 |
| Irenes | but it could have been 0-RTT | 00:18:44 |
 clerie joined the room. | 07:04:35 | |
| clerie | 07:05:52 | |
 sky1e | Hi, I'm new to Gerrit and the semantics of the minus votes on gerrit isn't explained in the review flow page on the wiki. I received a -2 "This shall not be submitted" on my change. Is this analogous to closing a PR, and mean I should just abandon the change? | 23:35:59 |
 Qyriad | -2 should be given witha comment explaining why or what conditions make it not suitable for merge | 23:44:06 |
| Qyriad | * -2 should be given with a comment explaining why or what conditions make it not suitable for merge | 23:44:14 |
| sky1e | Okay. I wasn't sure if it meant "fix this and we can continue discussing" or "don't bother, this is unworkable". I figured being a -2 instead of a -1 it has to mean something stronger than a basic "please make changes" | 23:55:22 |
| 25 Apr 2025 | ||
 Winter | Qyriad: FYI, haven't forgotten about your comment on https://gerrit.lix.systems/c/lix/+/3011 -- this issue just got a lot more wacky and I'm trying to get to the bottom of it. | 00:08:20 |
| Qyriad | In reply to @sky1e:mildlyfunctional.gayfeel free to ask a clarification | 00:11:27 |
| Irenes | I'm certain nobody intended to tell you to go away without even commenting on why, it's a good group | 01:39:22 |
 KFears (burning out) | In reply to @sky1e:mildlyfunctional.gayOh, I see, yeah the confusion makes sense. I'll add this information to the wiki. We don't really have it written down anywhere and I don't think it was ever explicitly discussed and agreed upon, but basically the scoring on reviews goes like this, from having looked at reviews for some months: +2 - looks good to maintainer, can be merged +1 - looks good to contibutor, needs another look from someone else 0 - changes requested; they'll be detailed in review comments -1 - disagreement with the change, or there's a strong blocker that makes the change not feasible for a long time -2 - not happening | 02:01:48 |
| KFears (burning out) | Hmm, actually getting second thoughts on -1 and 0 meaning... I guess different people do it differently. Uhh we should probably decide what means what | 02:14:04 |
| KFears (burning out) | Imho getting -2 is kinda frustrating and should happen as rarely as possible I glanced over the CL and I'm not super sure where the CA infra horrors mentioned comes into play but the change looks a little scary to me. If it touches CA stuff like FODs then it might be hard to merge it before we improve the testing and code structure | 02:28:31 |
| 26 Apr 2025 | ||
 jade_ | i think that we are not trigger happy enough with the -2 in that it is just a stronger signal that it must be changed before approval; in general -1 means the same thing: it should not be approved by another maintainer. but for the most part they mean the same thing, which is that the change isn't acceptable in its current state. there should be a comment to say whether it is a permanent veto on the approach or if it just needs rework. often times what might sound like a permanent veto is actually just a very strong rework request that likely necessitates starting from scratch. in general the goal is that people don't wind up getting their stuff veto'd because it feels bad to do and it feels bad to receive! | 05:49:07 |
| jade_ | * i think that we are not trigger happy enough with the -2 in that it is just a stronger signal that it must be changed before approval; in general -1 means the same thing: it should not be approved by another maintainer. but for the most part they mean the same thing, which is that the change isn't acceptable in its current state. there should be a comment to say whether it is a permanent veto on the approach or if it just needs rework. often times what might sound like a permanent veto is actually just a very strong rework request that likely necessitates starting from scratch. in general the goal is to have sufficiently effective project management that people don't wind up getting their stuff veto'd because it feels bad to do and it feels bad to receive! | 05:49:32 |
| jade_ | that is incorrect! | 05:49:48 |
 K900 | Can more people with remote builders running weird shells please test https://gerrit.lix.systems/c/lix/+/3046 | 05:49:49 |
| K900 | (yes I remembered about this because you're a xonsh user) | 05:50:05 |
| K900 | I think we finally have a design that actually, uh, works, somewhat | 05:50:26 |
| K900 | And doesn't require gutting the entire remote store API | 05:50:43 |
| jade_ | the code review labels are used for their technical functionality only! that is: +2 - you can submit it now +1 - someone else needs to approve it but lgtm. can also mean "i could be convinced to +2 it if something is clarified" 0 - maybe request changes, maybe "I am unqualified to approve and have neutral vibes, but here are some comments" -1 - I don't like this change in its current state. someone else could stamp it in unusual circumstances. -2 - I don't like this change in its current state. it will not be merged without rework. usually this is used as either: veto, severe bug identified, or ensuring that rework happens before merge. | 05:52:56 |
| jade_ | warning about apple having a stupid fork of openssh that has closed source keychain integration and at one point missing ed25519-sk support (maybe fixed now?). because of course they do. and people even use it sometimes. | 05:56:03 |
| jade_ | no decision has been made on that. if you standardize on a reasonable and normal one that is the typical community standard for modern code and document it, then it can be the standard. | 05:58:10 |