Release Engineering Meeting Recap from Monday 16-APR-07

[Axel Thimm]

On Tue, Apr 17, 2007 at 07:00:39AM -0400, Jakub Jelinek wrote:
> 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,
> ...).

When did these backports happen between 4.1.1-30 and 4.1.2-8 or earlier?

> If gcc, binutils or glibc changes substantially in say F8, we'll
> of course need to do a mass rebuild.

gcc should finally have made it to 4.2 by then.

> 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.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070417/9f27184c/attachment.sig>