| 22 Nov 2024 |
 Tomodachi94 (they/them) | share/ant is the convention used by Debian and possibly others | 17:04:41 |
| Tomodachi94 (they/them) | ...and tons more too, see PR description: https://github.com/NixOS/nixpkgs/pull/358204 | 17:31:00 |
| Tomodachi94 (they/them) | * ...and tons of other distros too, see PR description: https://github.com/NixOS/nixpkgs/pull/358204 | 17:36:09 |
|  Morgan (@numinit) joined the room. | 17:50:01 |
| Tomodachi94 (they/them) | Welcome :) | 18:06:14 |
| Morgan (@numinit) | howdy :-) | 18:12:53 |
| Morgan (@numinit) | gradle2nix kind of rules my day job in certain ways, noticed that this exists and figured I'd poke my head in 😛 | 18:15:46 |
| 23 Nov 2024 |
| Tomodachi94 (they/them) | I'm wondering if we should make a temporary branch in Nixpkgs for all of my Ant refactors devel-ant, PRing from my fork into the branch. From there, merge devel-ant' into staging`, then delete it once it's done | 00:51:10 |
| Tomodachi94 (they/them) | I'm wondering if we should make a temporary branch in Nixpkgs for all of my Ant refactors devel-ant, PRing from my fork into the branch. From there, merge devel-ant into staging, then delete it once it's done | 00:52:54 |
| Tomodachi94 (they/them) | I'm wondering if we should make a temporary branch in Nixpkgs for all of my Ant refactors devel-ant, PRing from my fork into the branch. From there, merge devel-ant into staging, then delete it once it's merged there | 00:53:08 |
| Tomodachi94 (they/them) | It would save rebuilds and ensure the refactors all hit at the same time, but I'm not sure it's standard | 00:53:39 |
 emily | how many commits are we talking here in expectation? | 00:55:34 |
| emily | we did a separate branch to PR into for https://github.com/NixOS/nixpkgs/pull/354107, though that was a ~2-person collaborative project that took a couple weeks | 00:56:09 |
| emily | rebuilds aren't an issue – staging isn't built | 00:56:19 |
| emily | (that's why we have staging-next) | 00:56:24 |
| Tomodachi94 (they/them) | In reply to@emilazy:matrix.org
how many commits are we talking here in expectation? Unsure. That depends on how many dependencies on ant-contrib there are | 01:06:26 |
| emily | my intuition would be that you can get away with just having a PR | 01:10:19 |
| emily | but I could be wrong :) | 01:10:22 |
| emily | rebuilds aren't worth worrying about anyway | 01:10:27 |
| emily | have you seen the CONTRIBUTING.md section about the stagling flow? | 01:10:37 |
| emily | we periodically cut staging-next from staging and that's what gets built on Hydra | 01:10:55 |
| emily | otherwise everything just queues up there waiting for the next -next | 01:11:04 |
| Tomodachi94 (they/them) | I'm mostly worried about the mandatory 1-week waiting period for modifications to packages (there are a few maintainers who don't appear to be responsive) | 01:13:41 |
| Tomodachi94 (they/them) | * I'm mostly worried about the mandatory 1-week waiting period for modifications to packages (there are at least a few maintainers who don't appear to be responsive) | 01:13:51 |
| Tomodachi94 (they/them) | And also worried about reviewer fatigue with one massive PR (and, since it would be a pretty big PR, keeping it rebased could become difficult if it sits for a while) | 01:15:33 |
| emily | that period is made up | 01:15:40 |
| emily | I don't think I've ever seen it followed other than for like "this package has an active maintainer and this is a significant breaking change" | 01:16:00 |
| emily | if we did staging like that every cycle would take two months | 01:16:15 |
| emily | FWIW I think you can also just do separate PRs directly into staging? | 01:16:38 |
| emily | it's okay to break stuff and then fix it as long as you have a plan for fixing it | 01:16:45 |
