[18/n] add target release generation to planning input #8401
Conversation
Created using spr 1.3.6-beta.1 [skip ci]
Created using spr 1.3.6-beta.1
Actually, I don't think this is quite right in general, though it seems to be the logic for |
Created using spr 1.3.6-beta.1 [skip ci]
Created using spr 1.3.6-beta.1
Updated this PR to also include the generation number for the old repo. See #8056 (comment) for some more discussion. |
| // This generation is successively incremented for each TUF repo. We use | ||
| // generation 2 to represent the first generation with a TUF repo | ||
| // attached. | ||
| let target_release_generation = Generation::new().next(); |
There was a problem hiding this comment.
Maybe just me, but I find Generation::from_u32(2) more explicit and therefore preferable for this kind of initialization. It keeps me from wondering (even though I know) whether the initial generation is 0 or 1 each time.
There was a problem hiding this comment.
Sure, I'm fine with either. Changed it to from_u32.
| }; | ||
|
|
||
| self.tuf_repo = new_repo; | ||
| // XXX: should this set old_repo to the current tuf_repo? |
There was a problem hiding this comment.
I don't see any reason why not, and I can't think of any other places where we'd want to do so.
There was a problem hiding this comment.
Honestly I'd say it's because old_repo is really the current release. This system doesn't enforce the invariant that setting a new target release is disallowed while an update is in progress (#8056 (comment)) so I think an unconditional self.old_repo = self.tuf_repo isn't quite what we want.
We may want to have a more explicit operation for this in the future, but it depends on how tests for this feature play out -- so I'd like to defer this until we get some more experience with that.
| .internal_context("fetching current target release")? | ||
| .internal_context("fetching previous target release")?; |
sunshowers
changed the base branch from
sunshowers/spr/main.18n-add-target-release-generation-to-planning-input
to
main
sunshowers
deleted the
sunshowers/spr/18n-add-target-release-generation-to-planning-input
branch
Add a new
TufRepoPolicystruct that currently consists of the target release generation plus theTufRepoDescription, and use it for bothtuf_repoandold_repo.We're going to need
tuf_repo.generationfor MUPdate override work (RFD 556). We don't anticipate needingold_repo.generationfor now but logically it makes sense to have.Depends on: