Disttags are nice, save the disttags

Jonathan Underwood jonathan.underwood at gmail.com
Tue Jun 5 11:39:05 UTC 2007


On 05/06/07, Jesse Keating <jkeating at redhat.com> 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.




More information about the Fedora-maintainers mailing list