measuring success

[Michael Schwendt]

On Fri, 02 Jul 2010 20:12:26 +0200, Till wrote:

> Btw. on a related issue:How do provenpackagers properly test for broken
> deps manually?

Every packager can [configure and] run repoclosure from yum-utils.
Enable updates-testing, and optionally add a local repo for your own
candidate builds. It should work with the default Yum configuration.

> The case where two updates in updates-testing are
> required to update one of them seems to me hard to ensure manually. But
> when only one of both updates is pushed to stable, there will be a
> broken dependency. I know that the fix is to bundle the builds of both
> updates into one, but how is this tested?

(I don't understand the question.)  Ordinary test-updates cannot break
other test-updates unless a koji buildroot override is involved.
For updates without a koji buildroot override, only when an incompatible
test-update is pushed to stable, it breaks dependencies of released
packages outside updates-testing and also becomes available in the koji
buildroot.

So, you don't have anything like "only one of both updates is pushed to
stable", because with a proper announcement of an incompatible update
*and* communication about a koji buildroot override, all needed rebuilds
should be known.  Whether you let one packager put them all into the same
bodhi ticket or have one packager push multiple tickets at once, is a
process/documentation issue.  There is no need to create bodhi tickets
before all rebuilds are available, btw.

For any update that isn't tested by the packager for incompatibilities
with previous releases (e.g. using tools from the "rpmdevtools" package),
so far it's important to not skip updates-testing and give me at least 24
hours to run extras-repoclosure (with stable test-updates entering nirvana
until they become available in the updates repo, there is a window during
which some packages are missing). For any incompatible test-update, the
package dependencies it will break will be discovered.

[About automating this during the push process, it is possible to have
a depchecker simulate a --skip-broken and exclude packages which break
dependencies. There are different strategies. However, the procedure
must be backed up by strong policies, or else we will see broken deps
whenever somebody skips the automated depchecking to push "something
important".]