Need proventester karma for firstboot-1.113-4.fc14 (was: Re: bodhi v0.7.9 deployed)

[James Laska]

On Fri, 2010-10-01 at 12:36 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > Again, you're extrapolating way too far from a single problem case. The
> > problem is simply that we have the xorg-x11-drivers metapackage which
> > requires every single X driver and is in the critpath. There's various
> > ways we could adjust this so it's no longer the case. It's hardly
> > something that renders an entire policy invalid.
> 
> Another example for how the critical path policy breaks things:
> https://admin.fedoraproject.org/updates/firstboot-1.113-4.fc14
> This update adds support for xfwm4 and openbox to the firstboot code. 
> Updates for those 2 window managers:
> https://admin.fedoraproject.org/updates/xfwm4-4.6.2-2.fc14 
> https://admin.fedoraproject.org/updates/openbox-3.4.11.2-4.fc14
> which add the virtual firstboot(windowmanager) Provides have already been 
> pushed to stable! So now we have 2 WMs satisfying firstboot's dependencies, 
> but not actually supported by its code. The result: the Xfce and LXDE spins 
> will be outright BROKEN. (And it's not my fault, I only did the firstboot 
> build and update requests, the other 2 packages were pushed by cwickert.)
> 
> I CANNOT push the firstboot update which UNBREAKS those 2 spins because of 
> the update policy. So instead of preventing breakage, the policy CAUSES 
> breakage! How can it fail more spectacularly for you to finally realize it's 
> a failure?
> 
> To all proventesters: please +1 that update, EVEN IF YOU HAVEN'T TESTED IT, 
> we need to get out of this impasse!

This is a bad idea.  I don't advocate supplying positive karma feedback
without following basic test procedures to verify the update is sane.  I
understand that sometimes things are out of ones' control, but lowering
quality standards to resolve this issue isn't a precedent I support.

In retrospect, if the three updates you list were in fact
interdependent, should they have been submitted and tested as a group to
avoid the current situation?

Thanks,
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101001/24ef6f45/attachment.bin