Break this in to issues by the "step".

As a whole I'm -1 at current state. This doesn't include impact assessment for individual steps on packagers(looking just on the first PR it looks like it is not backwards compatible and it not mentioning that). This doesn't include any docs(not even documenting how it will be behaving, if user docs are "useless") or plans to write some, definitive blocker for me.

Everything is documented both in the code and as examples (not my problem if redhat-rpm-config authors want to merge code without the associated documentation. I did the documentation work work).

And if by "backwards compatible) you mean (PR51) it is perfectly backwards compatible because it adds new entry points, it does not remove existing ones.

@nim looking at the PR51 you are removing without any compatibility layer forge-meta macro, but i have no knowledge of lua so I might be getting that wrong(it might be just internal function??).

It's an internal function, and it's not removed it's just renamed so the lua code can just call

forge.meta()

instead of the awkward

forge.forgemeta()

Its only user right now is the macro code in redhat-rpm-config, it will be called directly by the lua code in the proposed go-rpm-macros, which is why fixing its naming now is a good idea. I think lua allows creating as many aliases as one may want in its function tables so it would be trivial to keep the old name in parallel (need to check). But why? That would just be old cruft to carry on forever, when the only existing forge.forgemeta() user is the redhat-rpm-config code in the first place, and go-rpm-macros will start using it directly as forge.meta()

And to the comment that they don't require docs, I would just say that if everybody is doing that wrong doesn't mean that we will do it too(I guess this brought you here to work on go macros at first place). And sure you have worked on docs in past, but you have provided non this time.

There are loads of working operational documentation in the project so any commit that changes naming or behaviour can update the documentation at the same time. Plus the functions and macros are heavily commented (unlike most rpm macros Fedora uses).

It’s not in the same formal format as before because the formal format took an enormous time to write, drifted from the actual technical implementation (because any change was resource-intensive), and FPC members basically told me

1. I was nuts to write it that way
2. no one was going to read, review or approve a wall of formal design FPC side.
3. to get to the point of how a Fedora Go spec was supposed to look like without digressing

And, actual Go packagers didn’t want to read it either, so they flamed me for lack of documentation because they didn't want to read the long formal text.

cross posting from issue #3

@nim in step 4(mind you even marked it as optional) you are talking about commented templates(applied guidelines) not guidelines(formal definition of what needs to be done and is expected behavior of the macros stack).

In Fedora guidelines are basically a reviewed packager cookbook not a formal definition. If you don’t believe me ask your FPC contacts or take a look at what’s in existing Fedora guidelines.