| 9 May 2022 |
Vladimír Čunát | I'd treat it the same as queued. | 09:06:41 |
Vladimír Čunát | A state somewhere between failure and success. | 09:07:05 |
Janne Heß | Hm, does that make the graph go up or not? :D | 09:07:56 |
Janne Heß | I currently skip all evals which have queued != 0 | 09:08:17 |
Vladimír Čunát | Hehe... you might estimate from the last status of the same job (skipping over queued and cancelled). | 09:08:39 |
Vladimír Čunát | But I understand if that's considered too complex to do now. | 09:08:55 |
Janne Heß | And potentiall to heavy for Hydra :/ If you cancel a whole eval, I'd have to crawl every build twice (or three times?) (the aborted build and the "last previous success/fail") | 09:09:43 |
Vladimír Čunát | Right, if there are too many of cancelled/queued, you probably want to skip that eval anyway. | 09:15:06 |
Vladimír Čunát | * Right, if there are too many of cancelled+queued, you probably want to skip that eval anyway (for now). | 09:15:20 |
Vladimír Čunát | But often it doesn't seem optimal to wait because of a couple straggling builds. | 09:18:20 |
Vladimír Čunát | * But often it doesn't seem optimal to wait because of a couple straggler builds. | 09:18:55 |
Vladimír Čunát | * But often it doesn't seem optimal to wait just because of a couple straggler builds. | 09:20:04 |
Janne Heß | So it begins | 10:04:09 |
Vladimír Čunát | https://github.com/NixOS/nixpkgs/issues/172160 | 10:05:28 |
Janne Heß | ah I should cross-post this to discourse | 10:05:55 |
| Robert Hensing (roberth) joined the room. | 10:25:45 |
Janne Heß | So Robert Hensing (roberth) grahamc (he/him): I wanted to finish up the discussion about the initial tag for the upcoming release. Graham said there might be tools that rely on the tag being named that way, do you think its enough to announce the upcoming change now and hope everybody relying on this fixes their scripts? I really understand Robert's motivation here and I think it would be a relevant improvement and make this more clear | 12:38:38 |
jonringer | In reply to @janne.hess:helsinki-systems.de So Robert Hensing (roberth) grahamc (he/him): I wanted to finish up the discussion about the initial tag for the upcoming release. Graham said there might be tools that rely on the tag being named that way, do you think its enough to announce the upcoming change now and hope everybody relying on this fixes their scripts? I really understand Robert's motivation here and I think it would be a relevant improvement and make this more clear The main thing is git describe | 16:13:16 |
jonringer | [09:14:21] jon@nixos ~/projects/nixpkgs (release-21.11)
$ git describe
21.11-3617-g1f8e77dfaea
| 16:14:35 |
jonringer | actually, for hydra this might not be too much of a concern:
version = fileContents ../.version;
versionSuffix =
(if stableBranch then "." else "beta") + "${toString (nixpkgs.revCount - 291486)}.${nixpkgs.shortRev}";
And this gets updated as part of the release process
| 16:17:25 |
Janne Heß | couldn't we just … not tag at all? | 16:19:55 |
jonringer | So, we used to tag because there was an explicit beta period | 16:20:40 |
jonringer | but I kind of did away with that with "ZHF on master" RFC | 16:20:57 |
jonringer | and just treated master during ZHF as the beta | 16:21:21 |
Janne Heß | ah the XX.XX-beta tag? | 16:22:03 |
jonringer | Yea | 16:27:08 |
jonringer | Also I'm getting married on saturday, and then going on a honeymoon soon after, so I won't be able to participate in this ZHF as much as I have in the past | 16:42:52 |
Linux Hackerman | Oh wow congratulations! | 16:43:04 |
Vladimír Čunát | I'd think ZHF is the perfect programme for a honeymoon 😏 | 16:46:31 |
jonringer | she would disagree | 16:47:05 |