depcheck test (was Re: measuring success)

[Luke Macken]

On 07/06/2010 04:09 PM, Till Maas wrote:
> On Tue, Jul 06, 2010 at 03:06:37PM -0400, Will Woods wrote:
>> On Tue, 2010-07-06 at 19:21 +0200, Till Maas wrote:
>>> On Tue, Jul 06, 2010 at 09:40:01AM -0700, Jesse Keating wrote:
>>>> On 7/6/10 8:52 AM, Till Maas wrote:
>>>>> IMHO it should not be a +1 karma but some different flag that is set for
>>>>> updates that passed the tests.
>>>>
>>>> Using karma is viewed as the path of least resistance to getting support
>>>> in current bodhi for this.  For future bodhi yes, it makes some sense to
>>>> use some different flagging mechanism.
>>>
>>> Essentially using a different flag is just re-using the code used to
>>> flag a package as critpath-approved only with a different name.
>>> Therefore it should not need that much more effort.
>>
>> Feel free to help write the code to prove this point!
>>
>>> Btw. using the "path of least resistance" to implement policy
>>> changes seems to be what makes the new workflows suck for package
>>> maintainers, e.g. with the change in place using a auto-karma value of 1
>>> will become 0.
>>
>> Well that's only one *proposed* idea. We could just as easily have
>> autoqa give a comment with neutral (0) karma on updates which pass, and
>> -1 on failed updates, which would serve all the same purposes. That
>> might be a better idea, actually.
>
> Using karma 0 the patch could be this one:
> http://till.fedorapeople.org/tmp/0001-support-passed_autoqa.patch

This patch looks good at a first glance -- it's pretty much exactly what 
I was planning to do.  The only tweak that is needed is to ensure that 
anonymous people can't pretend to be AutoQA:

-            if comment.author == "autoqa":
+            if not comment.anonymous and comment.author == "autoqa":

This patch, along with my critpath/nofrozenrawhide/epel changes, avoid 
making database schema changes to bodhi.  This makes it very easy to 
perform upgrades.  For the TurboGears2 port of bodhi that is underway, 
these flags should definitely be proper columns in the db model. 
Another benefit of the TG2 port is we will be able to utilize the 
SQLAlchemy migration tools, which will allow us to change the schema as 
we need to, instead of hacking together these "path of least resistance" 
changes.

Thank you for all of your help with Bodhi, Till.  Your work is much 
appreciated.

luke