measuring success

[Till Maas]

On Sat, Jul 03, 2010 at 12:27:50PM +0200, Michael Schwendt wrote:
> 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.

This is not true, because there can be runtime dependencies on another
update in -testing that is not build dependency, e.g. if an python app
requires a newer version of a python module.

> 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.

Just requiring proper communication will lead to failure, because e.g.
new maintainers might not know some of these problems and autokarma
pushes one of the dependent updates to stable but not the other. And
this already happened with a highly used package.

Also Bodhi does not allow to fix updates by other people than the update
submitter afaik. Also it is not possible to e.g. add my new package to
some other update to ensure atomicity. E.g. when I wrote
fedora-easy-karma, it needed a version of python-fedora that was only in
updates-testing. But there was no easy way for me to ensure in Bodhi
that f-e-k will only be pushed to stable after the python-fedora update.
The only supported way other than ensuring it manually is to ask the
python-fedora update submitter to include the f-e-k build. But then all
changes wrt to the f-e-k build need to be proxied through the
python-fedora submitter, which just means double work. And it also means
that for the manually method I need to ensure that autokarma is off, but
it also tries to re-activate itself with every update edit.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100703/f1209468/attachment.bin