There's some edge cases to consider:

Some packages botched their conversion to rpmautospec and set Release themselves, but have %autochangelog. This results in broken packages when using rpmdev-bumpspec (like during the mass rebuild), i.e. here, resulting in bogus commits like this one.

There's also the question of what to do with the "Generated by rpmautospec BEGIN / END" block in the spec preamble - I think it should be dropped when un-rpmautospec-ifying a spec file. But at that point, parsing for this block will be brittle, and broken if the user (accidentally or not) modifies it. (Believe me, I have seen people do weird things with "AUTOMATICALLY GENERATED; DO NOT EDIT!!!" sections ...)

There's also the question of what to do with the "Generated by rpmautospec BEGIN / END" block in the spec preamble

My idea was to drop it. It'd be really strange to leave it in.

But at that point, parsing for this block will be brittle, and broken if the user (accidentally or not) modifies it.

Yes, we can't do much in that case. But the goal is to handle the "normal" scenario. This will be 99+% of cases. People are supposed to review the result of fedpkg import anyway. The user will always be able to outsmart the automation, I don't think this is much of an issue.

I have just several random idea, maybe more for rpmautospec then here, but I'll include all :)

1. Why rpmautospec does not generate something like Provides: rpmautospec(....). That way, we could query if the rpmautospec was used.
2. Shouldn't we include Buildrequires: rpmautospec in the .spec files which includes this feature? I think we should.
3. I am using fedpkg import while generally having the original spec file around, so maybe it could be reused.
4. Generally, I am using fedpkg import because there is nothing better to upload sources + add/remove patches in one sweep. Maybe it would not need necessarily work just with SRPMs. My workflow is typically: git add -u; git commit; fedpk import SRPM; git commit --am
5. I don't remember to use fedpkg import outside of dist-git repository.

I have just several random idea, maybe more for rpmautospec then here, but I'll include all :)

1. Shouldn't we include Buildrequires: rpmautospec in the .spec files which includes this feature? I think we should.

This is wrong. rpmautospec is not even used at package build time, but only as a pre-processing step when constructing the SRPM. This is handled locally and in koji by fedpgk srpm, and both environments always have rpmautospec macros defined because they are a hard dependency of redhat-rpm-config. The SRPM files produced this way don't even rely on the rpmautospec macros being defined anymore - %autorelease gets locally defined in the package spec header, and %autochangelog is replaced with the actual changelog contents.

1. Generally, I am using fedpkg import because there is nothing better to upload sources + add/remove patches in one sweep. Maybe it would not need necessarily work just with SRPMs. My workflow is typically: git add -u; git commit; fedpk import SRPM; git commit --am

Just side note: In my mind this is a very unusual workflow. I don't think we crecommend to use fedpkg import anywhere other than "import this package into Fedora dist-git" (which only happens once per package).

Just side note: In my mind this is a very unusual workflow. I don't think we crecommend to use fedpkg import anywhere other than "import this package into Fedora dist-git" (which only happens once per package).

I disagree. That is exactly my workflow and I have just run into this issue and entered a ticket here:
https://bugzilla.redhat.com/show_bug.cgi?id=2177329
So, we do recommend to use it.

I learned the import workflow out of an issue I was having and reported it on the devel list years ago: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BC65GAULZEJFR4O5HRT2EPRASESCLBU6/

It appears from the first post from @zbyszek that we have a solution. Does anyone know when it will be implemented?

My idea of fixing this:

1. Add a new command to rpmautospec, revert-distgit, which reverts that 'process-distgit' does.
2. During 'fedpkg import', check if srpm has been run through process-distgit,
   if so, run it through revert-distgit.

I intend to implement this solution.
As for when, I cannot say, I am a volunteer and, unfortunately,
lately other things have eaten all my time so I have not been able to to work on Fedora.

I already practiced for step 1 by implementing revert as the inverse of convert in rpmautospec#292.