Re: Release Engineering Meeting Recap from Monday 16-APR-07

[Jakub Jelinek <jakub redhat com>]

On Tue, Apr 17, 2007 at 10:13:11AM +0200, Axel Thimm wrote:
> o The choice of what to rebuild or not requires more developer time
>   than fixing broken rebuilds: Currently some heuristics were uses to
>   cherry-pick what to rebuild. This requires a careful examination
>   that if doen properly consumes as much or more developer time than
>   to fix any broken rebuilds. If not done careful, then some
>   dependencies will be missed. For example the current upgrade sees
>   the following changes in the buildtools
> 
>                  FC6               F7
>    gcc           4.1.1-30          4.1.2-8
>    glibc         2.5-3             2.5.90-20
>    binutils      2.17.50.0.3-6     2.17.50.0.12-3
> 
>   Perhaps the gcc or binutils changes are not that big, but the glibc
>   ones seem to be, e.g. 2.5.90 is the prequel to 2.6 and just checking
>   the API (the glibc-headers) gives:
> 
>    41 files changed, 297 insertions(+), 220 deletions(-)

Even the glibc changes in F7 are mostly glibc internal changes, bugfixes
and addition of a few new symbols (epoll_wait, sync_file_range,
strerror_l, __sched_cpucount) and only on PPC a new version for existing
symbols (pthread_attr_setstack{,size}).  So neither gcc nor glibc
changes necessitate a mass rebuild (and I'm not aware of any huge changes
in redhat-rpm-config either) at this time and that's why F7 rebuild status
is so low.  GCC 4.2 has been stagnating for 6 months now and we have
several important things backported anyway in GCC 4.1.x-RH (OpenMP,
visibility stuff, Java stack, numerous Fortran improvements, many bugfixes,
...).  If gcc, binutils or glibc changes substantially in say F8, we'll
of course need to do a mass rebuild.

I'd note that sometimes it makes sense to rebuild all packages, including
noarch ones, e.g. when there are significant rpm-build, redhat-rpm-config
etc. changes that affect all packages.

	Jakub