On 1/15/06, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxxx> wrote: > 1) Create a FE5 blocker bug. > 2) Open a rebuild bug for every package in devel and add it to #1. > 3) Maintainers rebuild their packages, fixing issues as they encounter > them. > 4) Close the bugs as they are completed. And what happens if maintainers fail to kick off rebuilds? Or there some sort of cascade such that an underlying dependancy package needs to be rebuilt at the same time as another package but package A and package B are maintained by different people? I've been in conversations with at least 2 people in #fedora now about weird oddness associated with extras-development rebuild attempts under mock where a chain of packages needed to be rebuilt together or else the rebuilt results failed. I really think an effort needs to be made to do a mass-rebuild and let notify maintainers based on the failures in that coordinated mass rebuild. The mass-rebuild tree doesn't necessarily need to be the normal public tree. But I think a mass rebuild should be attempted and the failures cataloged to see exactly how bad the gcc change has been for Extras. How long would it really take Core development to get its packageset rebuilt if each Core maintainer was individually responsible for rebuilds after the gcc changes? Instead of having a coordinated rebuild like Jesse pushed through the meatgrinder? -jef -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
