kbendick commented on issue #4000: URL: https://github.com/apache/iceberg/issues/4000#issuecomment-1024718266
100% agreed, once it's working one file is nice, but I will admit that i had to clean up from failing midway through (the `version.txt` commit which I moved to be further down at some point, but obviously not far enough). I agree that if we're looking to have more people involved in the release process, it might be better to break it up more. I feel it makes sense if possible to have a separate script that ensures one has all of the permissions? Ensure that the code signing key exists as well as checking `svn` permissions. Do we know if there's any guidance from ASF on ways to check those things? That seems like a good first step. A possible source of inspiration in breaking it up could come from Flink: https://github.com/apache/flink/tree/master/tools/releasing Some of it could possibly also be pushed into gradle tasks, to allow us to escape some of the bash knowledge needed. I'm open on ideas as to how to split it up, but here's one idea: 1. `pre-source-release.sh` - ensure all permissions, executables are on the path. 2. `tag-and-commit.sh` - step one above. 3. `create-and-sign-tarball.sh` 4. `all-svn.sh` - add tarball, signature, checksum to svn 5. `post-source-release.sh` - email template file. Breaking it up into named bash functions first might help (no argument ones that pull from global variables for simplicity's sake). That way, each block is more independent. From there, that might give us a better idea on how to break it up. One thing is that if we want release managers that don't have all of the permissions, we should definitely move the signing and `svn` stuff, as somebody else has to do that for them. But it would be nice if they could still commit the `version.txt` file or handle enough of it to be able to pass it off easily. -- 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]
