182 pending F11 stable updates. WTF?
mschwendt at gmail.com
Tue May 12 09:15:45 UTC 2009
On Mon, 11 May 2009 23:03:01 +0200, Kevin wrote:
> What happened is that people inadvertently built Qt-based packages which did
> not require a rebuild and thus weren't on our radar against the Qt 4.5
> buildroot override, then pushed them to stable while Qt 4.5 was still in
That's no example for what Ralf has written:
| Fact also is: "Testing" occasionally is the cause of broken package deps.
As soon as the new Qt got tagged into the buildroot, *any* build done
against Qt required coordination with you (or whoever decided when to
release the new Qt and the known rebuilds).
Even if the new Qt and the known set of rebuilds had been pushed directly
to stable as quickly as possible, you could have missed builds done by
other people. These builds would be mostly harmless if they go to
updates-testing first. Not so for packages that go directly to stable.
Treating the new Qt and the known rebuilds like hot potatoes is no
solution for race conditions like that. Computer aided release management
is needed. Especially if you say some packages segfaulted if not rebuilt.
Push "all deps or nothing" from testing to stable: the new Qt and any
builds done against it, but not a partial set of packages. Buildroot
overrides that do more than just "poison the buildroots". Buildroot
overrides that could tell the updates system to disallow Qt deps from
being published before Qt. The Updates System taking into account the RPM
inter-package dependencies, so a person who edits the Qt update request is
shown the list of dependencies in the updates queue similar to bugzilla's
"blocks/depends on" chains.
More information about the devel