releng: use worktrees for git state handling, and consider also making a worktree of the other projects to do their releng #439
Labels
No labels
Area/build-packaging
Area/evaluator
Area/flakes
Area/language
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/store
bug
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
ux
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#439
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Currently our own tag pushing code is broken since gerrit doesn't accept tags with commits it's not already seen. So we would probably want to push for review to
release-2.90
or so.Also, it's not made clear to people who didn't write the release scripts that
releng tag
will tag the version and go into detached HEAD, but that detached HEAD should not be merged to the release branch. Rather, the release branch locally should instead be pushed for review.Overall the git state management of this is very cursed, and I wonder if it should just be done in a temporary worktree or something to reduce confusion.
I think the way this should evolve is that we have a "releng workspace" where we grab each other project and create worktrees of each from which the releng is done. Then the releng code exists in lix itself, or it moves outside, either way is fine.
We can then reuse releng work for fixing up flake inputs between the nixos module and the installer, among other things.
releng: clarify the git state and fix git tags/non-tags push *somehow*to releng: use worktrees for git state handling, and consider also making a worktree of the other projects to do their relengThis issue was mentioned on Gerrit on the following CLs: