sbp commented on issue #753: URL: https://github.com/apache/tooling-trusted-releases/issues/753#issuecomment-3954641562
When a release is announced, we freeze all the files in a directory in `state/finished/` in ATR. We also pseudo-publish these in a fake distribution area called "downloads" which is intended to simulate the eventual SVN directory and its downstream distribution websites. So we have `ATR finished` which is immutable, and we have `ATR downloads` (in alpha) or `SVN downloads` (in beta and onwards) which are mutable. All three of these areas only exist _post-announce_. Before a release manager uses the announce form, their files do not appear in any of those areas. Before announce, ATR has a directory called `state/unfinished/`. There are three phases in ATR: compose, vote, and finish. All of these use the `ATR unfinished` directory. You can create new revisions of your files in the compose and finish phases. Then you announce and the files go into `ATR finished`. They will also be linked into the `ATR downloads` (and eventually `SVN downloads`) areas. When testing with @hboutemy, the fact that we allow the creation of new revisions in the finish phase was confusing. In a meeting with @dave2wave today, he suggested off-hand that revisions could be fixed as soon as a vote starts. In other words, we could disallow release managers from creating revisions in the finish phase. This means that we would not have the file management interface to move files in that phase: we would remove that interface. But there's another alternative. We could consider that interface to be the _planner_ for the `ATR downloads` or `SVN downloads` directory. We would freeze the release files as soon as the vote is started. When the vote succeeds, those files would still be frozen and ATR would retain them as a permanent record forever, internally. But the release manager should be able to rearrange and reorganise the downloads area as they see fit. From their point of view, they would be able to move and delete files (subject to certain constraints, such as not being able to change extensions; and perhaps we should be stricter than that). They would not be able to add files. But they would always be able to undo changes etc. From the ATR development side, we could have "revisions" of the downloads area. We would no longer need revisions in the finish phase. But we might not even need revisions of downloads either, because they would be tracked via SVN, so if we needed to revert then we could consult SVN history. It depends how efficient we need this to be. This might be more intuitive to release managers because the fact that ATR keeps a frozen copy of files is, as @hboutemy pointed out, an implementation detail. -- 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]
