Coming from https://github.com/hpcng/rocky/issues/4
I also suggest Rocky Linux should have well and good documentation. As I notice currently many experience RH and CentOS developer come and join force to build Rocky Linux, which to me this is great time to document the technique for newcomers references
Agree documentation is really important. At nethserver (centos based) we use readthedocs with the option to edit/add on github. This way this can be a true community effort, which idea I do like.
Good point. I guess the BSD manuals give a great high-level overview. There is a lot of more specific information in the CentOS wiki:
And then there are probably resources from SL too… Would be great to gather and modernize this knowledge.
Edit:
This is very practical and useful:
I like No you can't just "sed s'/Red Hat/CentOS/' (someone always offers that)
The link you put is useful in general but not practical. We need more details step by step documentation
What about we start designing the process of cloning some repo (CentOS for “fresh” start), building it, adding some scripting to advance the heavy duty, and then fetch packages to a local repo FTP server, and then the mirror. By the end, the complete bundle build of what would be Rocky.
Thus, we start to do baby steps in sandbox and as a prize we got a reproducible cycle, with “do-break-learn-refactor-release” lean process to the score 
Agree. Count me in for documentation(en,de).
Hi since you said count you for documentation then you should be know the steps. Could you post the “draft” here. Later on when wiki is up, we can put there. 
Well since you know the general. Can you share here? Later on someone will extend and do corrections
that’s sad that there is still nothing…
This is quite the old topic…
Unfortunately there’s no “step by step process” to doing a rebuild of RHEL. It unfortunately is not that simple nor cut and dry as there are too many variables and just too many moving parts. Ultimately what it comes down to for a project to make a rebuild is identifying what has to be done at a minimum and then building the foundation around it to do so, to allow the team to figure out what was missed or what can be done to improve the process. We generally know these to be true but not limited to:
With a general baseline, it is then that the plan of action is set forth. It has to be determined, what build system will be used, or in the case of already having one, how will we automate the process? Let’s look at Rocky 8 for example. We followed most of what we could from our upstreams, CentOS Stream, Fedora, and RHEL and used koji. So we essentially needed at a minimum:
Our koji setup is done via ansible and the playbooks are available in our (soon to be deprecated) monorepo. The roles are also in our organization.
We then built automation around it with a tool called srpmproc to do imports, patching, and the like, as well as integrated it into koji as a wrapper to pull package sources. distrobuild was made as the automation around this though it is semi automated. pungi is then used to “compose” the repositories and images, to which we send off to our mirrors.
For Rocky 9, we took what we learned and decided to do things a bit differently. The premise is the same with git and srpmproc, but now the build system, peridot, does all the building and composes for us, including assisting in image generation (like iso’s). It is then just a matter of doing a reposync to pull everything down and transfer to our mirrors.
Most of what we do day to day, at a high and medium level is documented throughout our wiki. It’s not perfect. One of our engineers did have a blog series in the past that explained some of what was done and some know how of how we got to where we here here.
In summary, there isn’t really a true step by step. There are guidelines and requirements laid out, and then the “plan” is built around those, starting from basic and usually ending up complex.
