depcheck test (was Re: measuring success)
opensource at till.name
Tue Jul 6 20:09:34 UTC 2010
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:
To make it pass autoqa run in sqlite3 /var/tmp/bodhi.sqlite
update comment set author = "autoqa" where update_id = 1435;
Instead of making it a bool, it might be also a good idea to use three
values: untested, passed, failed and in case if failed a pointer to the
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100706/64a4ac8b/attachment.bin
More information about the devel