Mass rebuilds

[Thorsten Leemhuis]

Axel Thimm schrieb:
> On Sat, Dec 09, 2006 at 07:13:16PM +0100, Thorsten Leemhuis wrote:
>> Axel Thimm schrieb:
>>> On Sat, Dec 09, 2006 at 12:06:58PM -0500, Jesse Keating wrote:
>>>> On Saturday 09 December 2006 11:55, Axel Thimm wrote:
>>>>> That would had been some packages too much (e.g. all non-python
>>>>> packages), but who really cares about bandwidth and rawhide.
>>>> Some?  There would have been a huge number of spurious rebuilds.
>>> So? Other than some CPU cycles wasted who would get hurt? 
>> Depends on how many packages we would use this scheme for. But I suspect
>> that in a lot of cases users that will update to the next stable release
>> (e.g. from FC6 to FC7 (or whatever it will be called) in this case)
>> won't like package updates just for the sake of rebuilding
> But let's face reality: For example how many packages survived w/o a
> rebuild from FC5 to FC6 in extras? 29! That's less that 0.5% of the
> whole repo. And note that only packages with a disttag would had been
> rebuilt anyway, so the whole point does not apply. E.g. any package
> with %{?dist} in the release will have to be rebuilt at some time from
> FC5->FC6 or FC6->FC7 anyhow.
> 
> So regular non-rawhide users are really not affected at all.

The last release maybe. The situation might be different with other
releases.

>> Yes, we did a lot of mass-rebuilds in for the last releases, but I hope
>> we in the future now and then have a release that can be realized
>> without mass-rebuilds.
> But we want mass rebuilds.

I was one of the key drivers in the last mass-rebuilds, but no, I would
not get that far to say "we want mass rebuilds" (each time).

> python 2.6 will also come one day, new
> glibc/gcc improvements as well. An improved set of %{optflags} and so
> on.
> 
> In fact mass rebuilds and a proper way to manage them are *something
> good*! And the disttag trick with fc6.89, fc6.89.1 etc is a very KISS
> implementation of doing sane and mostly unattended mass-rebuilds.

If we really want to rebuild all the stuff each release: yes. But it
seems at least some people do not like the idea of a complete
mass-rebuild each time (and/or even between the betas again).

BTW: There was a strong opposition when we did the first mass-rebuild
for FE (and that was really needed iirc).

> [...]
>>> In fact frequent mass rebuilds would disclose bugs that have gone
>>> by unnoticed, e.g. when a package's direct or indirect build
>>> dependencies change and the maintainer missed to notice that it
>>> affects his package indeed.
>> Agreed, but we could simply build them to a scratch repo that never gets
>> pushed. Tata, we have a similar effect without disturbing users.
> Some bugs are found at build-time, others at run-time. No one will test
> a scratch repo.

Sure. But is the rebuild one really better, even if there was no reason
for a rebuild? I would prefer a known good rpm over a rebuilded one when
there was no need for a rebuild.

>>> [...]
>>> The point is: Keep the given man power of contributors to being
>>> creative, therefore automate as much a possible.
>> Agreed. Thus I think we should work towards something like this:
>> "If the maintainer of foo updates foo to a newer version with a
>> different API/ABI then he should request rebuilds of all packages that
>> this update might break."
> But how is that different from the current situation?

Yes. Jeremy did a god job preparing the update and he even kicked off
the build of the other Core packages. But Extras was left out. We should
try to cover Extrs the next time directly, too.

> What you suggest
> is OK as a heads-up, but doesn't cut on the time expenses of both the
> maintainer of the base package, as well as the maintainers of
> dependent packages.

It does, The script worked quite good the last time I used it. If
someone would have kicked of this script (not that much work, but to
much for two packages) I for example would have saved 10 minutes today
as I had to manually queue the rebuilds of two packages.

> [...]

/me will probably stay quiet now and wait for others to speak up before
further commenting in this thread

CU
thl