See also issue #701.

It should also be possible to delete or replace an uploaded file.

It should also be possible to delete or replace an uploaded file.

This has been disabled in purpose: https://pagure.io/pagure/issue/1666

What if I accidentally upload the wrong file (e.g. a personal file that I'd like to remove immediately)?

No deletion/replacement would make sense if the tarballs were automatically generated (as it's in github). And probably this is what Pagure should do.
But a release may include other files, generated by the source code but not included in it. These files must be manually uploaded. What if something goes wrong?

Then that person should ping an admin and take the appropriate measures depending on what was published.

In my opinion, tarball releases should be generated from the git tag via 'git archive' and it should make it clear who signed the tag (and mark it clearly when it's not signed). Git tags are re-writable so if someone does want to change history (obviously not recommended, but there are, of course, reasons) they can.

Manually uploading a tarball seems... odd. So does asking an admin to intervene.

@jcline sure, arrange it for your projects like this but making it mandatory is pretty overboard.

Not only export-subst is a poor pre-processing you want to do with some projects for which there may be a crucial difference of the git contents and fine-tuned, curated release tarballs with GPG signatures etc. arising from the different styles of consumption/audience (git for people to hack on the project, tarball for the users). Definitely it is, on purpose, for https://pagure.io/clufter.

I'd like to be able to associate a release page with release notes and various highlights per release. I have release pages (wiki pages) for projects migrated from fedorahosted that have not found a proper place yet.

I also prefer to upload my tarballs which have all the proper make distcheck run to generate them so they are redy to be built by a user, I do not mind if someone can also download a tarball made on the fly from a tag, but it should not be the only method.

I could upload a release-xyz.html in the release area, but the fact you need admin intervention to correct mistakes made back out from doing that because in my experience it takes 2/3 edits to a release page before it is done.

It would be nice is the release area was backed by a git tree that has the hashes of the files uploaded automatically committed to it so that it is easy to see if/when a tarball was replaced, that way you have transparency, tracking and and flexibility. I think you could just reuse most of the "issues"/"pull requests" code for such a "releases" page. As all it is is really just a special kind of issue (title, text, potentially even comments) with file attachments (the tarballs).

The last update was 5 years ago, no further requests, updates or actionable tasks since then, I'm going to close this issue for now to reduce our backlog.