sbp commented on issue #33:
URL:
https://github.com/apache/tooling-trusted-release/issues/33#issuecomment-2816020683
The current idea of RELEASE_CANDIDATE_DRAFT ("Compose") and
RELEASE_CANDIDATE_BEFORE_VOTE ("Review") is that drafts ought to be frozen
before the vote announcement is made. We could freeze the draft when the vote
announcement email is sent, instead, but that opens the possibility of a race
condition. If the draft is still editable, the RM could look at the draft,
think "it's ready for the vote", and then another participant could edit the
draft just before the vote email is sent.
It's the same case with RELEASE_PREVIEW ("Prepare") and
RELEASE_BEFORE_ANNOUNCEMENT ("Announce"). The Announce phase is just Prepare
once it's been frozen. In this case a race condition is less likely, however,
because the number of contributors allowed to edit the release at Prepare stage
should be minimal, carefully controlled, and audited. Similarly, the range of
edits that are allowed to be performed should be strictly limited. Despite
this, there would probably be multiple people with the permissions to make
edits during the Prepare phase, and so a conflict is once again possible.
We could think of these pairs of phases (Compose and Review, and Prepare and
Announce) as being a single phase with a mutability bit set instead. Compose
(mutable) and Compose (immutable); Prepare (mutable) and Prepare (immutable).
We'd have to have a good think about how to make the UI for this clear to
users. What we really want to discourage is making a release immutable and then
immediately promoting it to the next phase. The point of making a release
immutable before it's moved to the next phase is that now it can be checked
without having to worry that the release is going to change after a review. For
simple releases with just a few files and a few contributors, this is unlikely
to matter very much. For releases with dozens of files, lots of last minute
changes, and other complexity, it's more likely to be important.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@tooling.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tooling.apache.org
For additional commands, e-mail: dev-h...@tooling.apache.org
