Release Engineering Meeting Recap from Monday 16-APR-07

[Thorsten Leemhuis]

On 17.04.2007 07:48, Dave Jones wrote:
> On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote:
>  > >   1. In the future we should consider a mass rebuild of all packages 
>  > > around, but no later than test2
>  > Hmmm, this was discussed in depth at the end of this thread:
>  > https://www.redhat.com/archives/fedora-packaging/2007-April/msg00017.html
>  > Some people would like to see a mass rebuild, some others are against it.
>  > 
>  > I'm one of those against it. Reasons:
>  > - Seems we have quite some users in country were internet bandwidth is 
>  > unreliable and costly. If we mass-rebuild everything each time those 
>  > users have to download a lot of new stuff where nothing changed besides 
>  > the release. that makes Fedora harder to use for them.
> And these users are running rawhide ?

Probably not, but they will have to download and install the new 
packages that got build during the mass-rebuild when they do the Fedora 
(x) -> Fedora (x+1 or x+2) update. Currently packages where nothing 
changed in between simply stay installed and no action is needed.

>  > - the update process gets much longer for each and everyone of us if 
>  > each package has to be downloaded and updated.
>  > - the packages out in the wild are tested and known to work. Rebuild 
>  > packages have to proof again that everything is fine (which should be 
>  > the case most of the time, but in rare cases isn't)
>  > 
>  > IOW: The benefits of a mass rebuild *each* devel cycle is IMHO not worth 
>  > the trouble we create for our users. I think a mass rebuild now and then 
>  > when the toolchain (things like gcc or other crucial stuff like rpm, 
>  > python,...) changed massively (round about probably every second or 
>  > third release cycle) is more then enough.
> 
> Yeah, I'll agree with that.
> Off the top of my head, I can come up with three scenarios where
> rebuilds make sense.
> 
> - Considerable bugfixes which fix up bad code generation.
> - new/enhanced features (such as more FORTIFY_SOURCE improvements)
> - new optimisations
>   (We could even narrow the scope on this one to rebuild just
>    packages that would show a notable difference.  Ie, don't
>    bother rebuilding fileutils, but do rebuild say, bzip2).

+1

> Taking a look at the packages in my f7 mirror, I spot 52 packages
> that still have a .fc6 tag, none of which look particularly
> "omg, we have to rebuild this".  There are also 713 with no %{dist} tag
> which include some which we definitly have rebuilt, so it's harder
> to figure out which of those got updated and which didn't.

Some numbers:

$ fc6release=$(date -d "24 Oct 2006" +%s); sudo repoquery 
--repoid=development-source --repoid=extras-development-source 
--archlist="src" -qa --qf '%{buildtime} %{name}' | sort | while read 
date name; do [[ ${date} < ${fc6release} ]] && echo ${date} ${name} || 
break ;  done | wc -l
1206

$ sudo repoquery --repoid=development-source 
--repoid=extras-development-source --archlist="src" -qa --qf 
'%{buildtime} %{name}' | wc -l
4073

$ echo $((4073-1206))
2867

IOW: 1206 out of 4073 source packages were not rebuild in devel (both 
core and extras) between release of FC6 and now.

CU
thl