And if someone very brave manages to make an ordered list of all the source RPMs by build order, in order to be able to rebuild them all without CentOS repositories at all, I promise to rebuild them and push them to the builddeps repo!

Only Citrix knows it, see if you can get this order from @johnelse.

https://updates.xcp-ng.org/7/dev/

Not usable yet for testing, but I invite you to start using it for RPM building and to report issues.

[xcp-ng-main]
name=Main repository for XCP-ng
baseurl=https://updates.xcp-ng.org/7/dev/main/x86_64/
gpgcheck=0
priority=1

[xcp-ng-builddeps]
name=Build dependencies for XCP-ng
baseurl=https://updates.xcp-ng.org/7/dev/builddeps/x86_64/
gpgcheck=0
priority=2

Note that if you install the yum-plugin-priorities package, you'll probably meet some errors when trying to install -devel packages from CentOS repositories. But that's a good thing in my opinion because that encourages us to rebuild the source RPMs corresponding to the exact version of packages in xcp-ng-main, to avoid build errors related to API changes (such as that of libdrm that breaks the build of qemu-dp).

And if someone very brave manages to make an ordered list of all the source RPMs by build order, in order to be able to rebuild them all without CentOS repositories at all, I promise to rebuild them and push them to the builddeps repo!
Actually, I think we might have to import some source RPMs from CentOS to boostrap the process, but afterwards we would have a solid build environment for 7.5

Im no expert of this but looks ok and usable to me except I feel community and community_testing are same because both are going to be supported by community only and pretty much always be in an experimental stage.

This may be true. I considered that community would mean "unsupported, but people used it with success" whereas community_testing would mean "untested, except by me". If you've got some driver RPM already in use by several in community and want to test a risky change, having community_testing available for that could be useful.

But we could also start without and add it later if need be.

Another suggestion, instead of community, you may want to mention "experimental" as it warns user. The project itself is a community-driven project and may not need another subdirectory showing "community" as some external set of members.

You're right. I thought of it and changed the name several times while writing the document but I finally came back to community, though it's probably not the best choice. My concern with "experimental" was that there would probably be some officially unsupported packages in it that would actually get good support from those who provide them. On the plus side, its name conveys an unambiguous meaning of "unsupported". On the minus side, it's hard to understand the difference between experimental and updates_testing without an explanation I think.

Other options:

• extras
• lab
• anything else?

community_testing is for those community-provided RPMs while still at an experimental state. Disabled by default, of course.

Im no expert of this but looks ok and usable to me except I feel community and community_testing are same because both are going to be supported by community only and pretty much always be in an experimental stage.

Another suggestion, instead of community, you may want to mention "experimental" as it warns user. The project itself is a community-driven project and may not need another subdirectory showing "community" as some external set of members.

My 2c.