 | Release Management | 338 Members |
| 25.11 "Xantusia" | https://nixos.github.io/release-wiki/Home.html | 93 Servers |
| Release Management | 338 Members |
| 25.11 "Xantusia" | https://nixos.github.io/release-wiki/Home.html | 93 Servers |
| Sender | Message | Time |
|---|---|---|
| 23 May 2024 | ||
 Arian | * Would it be possible to add the Currently the AMI upload script is having the image on releases.nixos.org would make the script a lot faster and waste a lot less bandwidth | 06:14:10 |
 vcunat | On the other hand it would make channels update slower and naturally we'd also pay for the storage. | 06:17:13 |
| Arian | in what way would make it the channel update slower? amazonImage is already part of the tested job | 06:18:58 |
| Arian | Redacted or Malformed Event | 06:19:48 |
| Arian | 24.05 boots successfully on Amazon 🥳 https://github.com/NixOS/amis/actions/runs/9203089651/job/25314015902?pr=132 | 06:22:53 |
| Arian | Redacted or Malformed Event | 06:23:48 |
| vcunat | In reply to @arianvp:matrix.orgThe update process needs to download the image from cache and upload it to the bucket. | 06:25:45 |
| vcunat | In reply to @arianvp:matrix.org* The update process needs to download the image from S3 and upload it to the bucket. | 06:26:07 |
| Arian | Gotcha. So we just move the slowness to somewhere else. Okay. I'll just keep it like this for now | 06:26:08 |
| vcunat | * The update process needs to download the image from S3 and upload it to the other bucket. | 06:26:14 |
| vcunat | For illustration, let me paste a bit of timestamped log from channel activation (these aren't visible publicly): | 06:29:02 |
| vcunat | All the three 24.05 channels are there. | 14:37:52 |
| vcunat | So I guess this will come soon: https://nixos.github.io/release-wiki/Branch-Off.html#once-the-channel-is-available | 14:38:25 |
| vcunat | Oh, looking at it, only the step (1) is missing, I think. | 14:40:20 |
 pbsds | it seems the release schedule does not detail when breaking changes are unrestricted on master. Should than be after branch-off, or after tagging the release? | 21:12:45 |
| pbsds | * it seems the release schedule does not detail when breaking changes are unrestricted on master. Should this be after branch-off, or after tagging the release? | 21:13:02 |
 raitobezarius | just after branch-off | 21:13:46 |
| raitobezarius | tagging the release happens on a parallel branch | 21:13:51 |
| pbsds | but this the week of backports. maintaining similarity between master and release-24.05 may be considered benefitial | 21:14:54 |
| pbsds | i commonly see comitters skip waiting for ofborg builds on backport during this week | 21:16:25 |
| pbsds | * i commonly see committers skip waiting for ofborg builds on backport during this week | 21:16:32 |
| pbsds | * i commonly see committers skip waiting for ofborg builds on backports during this week | 21:16:41 |
| raitobezarius | In reply to @pederbs:pvv.ntnu.no?????????? | 21:18:25 |
 Lily Foster | In reply to @pederbs:pvv.ntnu.nosimilarity yeah. RMs can better say/change when breaking changes are unrestricted. it should probably be clarified in release wiki though (and posted schedules) | 21:18:26 |
| raitobezarius | skipping ofborg builds is not acceptable under any circumstance | 21:18:38 |
| Lily Foster | In reply to @pederbs:pvv.ntnu.no(this is a huge problem that needs to be addressed then) | 21:18:39 |
| raitobezarius | a backport is already a quite involved action | 21:18:46 |
| raitobezarius | skipping their CI is really unacceptable without a proper provided rationale before the merge or something | 21:19:02 |
| Lily Foster | In reply to @raitobezarius:matrix.org(well skipping eval checks at least. builds can be separately verified) | 21:19:09 |
| Lily Foster | (which i wouldn't clarify except that the aarch64-darwin build queue exists......) | 21:19:31 |