mmaslano at redhat.com
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 (https://fedoraproject.org/wiki/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 .
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 . For example here were testers happy because it was
updated without any warning message, but they don't know if it's working
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.
More information about the devel