bodhi statistics

Marcela Mašláňová mmaslano at
Wed Jun 9 07:35:37 UTC 2010

On 06/08/2010 10:51 PM, Luke Macken wrote:
> I recently wrote some code to generate detailed statistics of Fedora&  EPEL updates within bodhi. Eventually this will be auto-generated and exposed within bodhi itself, but for now here are the initial metrics.
> This report definitely conveys the shortcomings in our testing, however, it does show us improving with each release. For Fedora 13, we implemented the No Frozen Rawhide process with improved Critical Path policies, which were definitely a success. With these enhanced procedures, along with the upcoming implementation of AutoQA and the new Package update acceptance criteria (, I think we'll see these numbers drastically improve in the future.
I can't agree that this update policy is success (in any dictionary). 
Since I'm forced to wait
two weeks for pushing into stable, I have more tickets about packages 
that I've already fixed. Users want fixes immediately, they are not 
interested in some processes. Many users don't even have FAS account and 
they want fixes and updates now. Not in next release as offer enterprise 
Other thing is that I'm forgetting packages in bodhi, because I believed 
until yesterday that updates will be pushed after two weeks 
automatically. Not sure whether policy changed or it's a bug [1].

Karma in bodhi updates doesn't speak about quality of updates at all. At 
least my packages which has more dependencies are pushed without 
testing, and less important are "tested" even testers don't know what 
does it do [2]. For example here were testers happy because it was 
updated without any warning message, but they don't know if it's working 
or not.

I'm looking forward to qa project that could really improve quality - 
like testing updates, which fixed bugs with bugzilla and testers really 
reproduce them before and not after. Otherwise is bodhi good only for 
checking update by yum without errors.

Best regards,


More information about the devel mailing list