Sat, 13 Dec 2008
Time spent in updates-testing purgatory
Will Woods asked me on IRC earlier today how easy it would be to determine the amount of time Fedora updates spend in testing within bodhi. It turned out to be fairly easy to calculate, so I thought I would share the code and results.
from datetime import timedelta
from bodhi.model import PackageUpdate
deltas = []
occurrences = {}
accumulative = timedelta()
for update in PackageUpdate.select():
for comment in update.comments:
if comment.text == 'This update has been pushed to testing':
for othercomment in update.comments:
if othercomment.text == 'This update has been pushed to stable':
delta = othercomment.timestamp - comment.timestamp
deltas.append(delta)
occurrences[delta.days] = occurrences.setdefault(delta.days, 0) + 1
accumulative += deltas[-1]
break
break
deltas.sort()
all = PackageUpdate.select().count()
percentage = int(float(len(deltas)) / float(all) * 100)
mode = sorted(occurrences.items(), cmp=lambda x, y: cmp(x[1], y[1]))[-1][0]
print "%d out of %d updates went through testing (%d%%)" % (len(deltas), all, percentage)
print "mean = %d days" % (accumulative.days / len(deltas))
print "median = %d days" % deltas[len(deltas) / 2].days
print "mode = %d days" % mode
4878 out of 10829 updates went through testing (45%)
mean = 17 days
median = 11 days
mode = 6 days
So, it seems that the majority of updates leave updates-testing in less than a week. This is interesting when taking into consideration the testing workflow mechanisms that bodhi employs. An update can go from testing to stable in two ways: 1) The update's karma can reach an optional stable threshold, and automatically get pushed to the stable repository based on positive community feedback. 2) The developer can request that the update be marked as stable. After an update sits in testing for two weeks, bodhi will send the developer nagmail, which seems to help mitigate stale updates. When initially deploying bodhi, I thought that we would get bogged down with a ton of stale testing updates and would have to implement a timeout to have them automatically get marked as stable. This is still a viable option (which would require FESCo rubberstamping), but I'm quite surprised to see how effective this community-driven workflow is already. Now we just need to encourage more people to use it :)
Due to the limitations of the current model I couldn't figure out an easy way to determine which updates were marked as stable by positive community feedback. This issue will be assessed with the long-awaited SQLAlchemy port that I will hopefully finish up at some point early next year.
posted at: 02:13 | link | | 1 comments
Posted by David Timms at Sun Dec 14 07:26:35 2008
how much would it take to morph that code to produce a distribution graph of:
no of packages vs days in -testing

