I'm fine with the recommendation, though it will only capture things that are actually filed as Changes.

While it's orthogonal to this ticket, the issues you've run into seem to make a strong case for continuous rebuilds in rawhide. I wonder how difficult it would be to accomplish that and then eventually tie it into a CI-like project where it is done on a per-commit basis for packages.

While it's orthogonal to this ticket, the issues you've run into seem to make a strong case for continuous rebuilds in rawhide. I wonder how difficult it would be to accomplish that and then eventually tie it into a CI-like project where it is done on a per-commit basis for packages.

This is getting off-topic, but as it happens, the Base Runtime team is working on doing exactly this, albeit initially for only the set of packages in their sphere of influence. The Modularity WG will likely expand that to other modules, but I don't know whether there are plans for the entirety of the Everything repo.

A comment to the sgallagh's recommendation: Currently, in the schedule, we already have a deadline for Changes requiring mass rebuild: "Change Checkpoint: Proposals requiring mass rebuild submission deadline" . This deadline is scheduled 4 weeks prior the mass rebuild it self, to make sure there is enough room for FESCo to review and approve and for RelEng to get ready for it. The problem here, as jwboyer pointed out, is to have such a change reported as a Change and recognize the need for the mass rebuild on time.

Yeah, I suppose that the detection of such events is the harder problem to deal with. I'm not sure what we can do to improve that.

And I suppose major buildroot changes are very infrequent, so maybe there's no generalized action to take here.

I'm fine with the recommendation, though it will only capture things that are actually filed as Changes.
While it's orthogonal to this ticket, the issues you've run into seem to make a strong case for continuous rebuilds in rawhide. I wonder how difficult it would be to accomplish that and then eventually tie it into a CI-like project where it is done on a per-commit basis for packages.

+1

I am not a fan of this recommendation. We have built into the schedules mass rebuilds and time to deal with the fall out. We have no way to determine if some change will effect the the proposed environment. I agree we should make sure that things are breakable.

Perhaps a better soultion would be someone writing a tool that looks at the packages installed in a packages buildroot and then comparing the BuildRequires, then doing an analysis of the code to determine if the package not installed by BuildRequires is actually used, resulting in us fixing the packing issues of incorrect BuildRequires that get highlighted when something like this happens