sbp commented on issue #286: URL: https://github.com/apache/tooling-trusted-releases/issues/286#issuecomment-3589882057
Information in the release policy is relevant throughout the release process, so we need to record the state before the final release too. Our release policy objects, and related forms, are structured so that fields are associated with each phase. Might it make sense to take an immutable snapshot of the relevant section of the release policy when that phase starts? Consider these vote phase policy fields, for example: email of the mailing list, manual voting process, minimum voting period. Does it make sense to change these _during_ a vote? Changing the minimum voting period, and expecting it to apply, could be very confusing for voters. Changing the voting process to allow it to be manually resolved may make sense, if there is a problem with the automatic voting interface, but we've designed it so that a vote can be failed anyway, and we will add a cancellation option. Changing the email of the mailing list does not make sense. If we freeze the relevant configuration section when a phase starts, this prevents race conditions and inconsistencies, but it means that we need to add some UI to show the current configuration options, because they may have been changed. Indeed, it would be useful to show any changes too. (We may even add or remove policy options from the database schema.) We do, however, need to make sure that this makes sense for all policy fields. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
