On 05/06/07, Jesse Keating <jkeating@xxxxxxxxxx> wrote:
You only solve at the point in which you do the rebuild. Doing such rebuilds really invalidates any QA done on the binaries up to that point, so you'd need to do it early, but then more changes happen throughout the release so you can't really feel warm and fuzzy at the end of the release that your rebuilds at the beginning of the release are still valid anymore. So unless we do rebuilds again at the end and introduce a long period of testing where no other builds but bugfixes (but even that changes things!!) are accepted you don't get your desired results. And then we have 1 or 2 month old builds in our release and we get trounced in the media for shipping old software, and people loose interest in fixing the release if we open rawhide during that re-testing period, and if we don't we get very upset maintainers who don't have anything to do... Seriously the only time rebuilds are really worth it is when you're rebuilding for a specific reason such as a gcc or rpm change. Then you ensure what you're rebuilding for is already in the buildroot, and you build things that A) make use of it, and B) haven't already been built. And you do these things before the Feature freeze.
Yep, I entirely see your point. It could also be summarized as "Fedora QA is binary RPM focussed". QA of binaries takes precedent over reproducibility of packages and the distribution, and changing that would be a fundamental change to the distribution. Is that more or less right ? [I'm not trying to be a jerk, but am trying to understand the details - one of us has years of experience as a release manager, and one of us doesn't :)] J. -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
