[Soc-coordination] Possible GSoC idea: (Near) real-time updates of (UDD) bug view

Lucas Nussbaum lucas at debian.org
Thu Mar 7 09:06:06 UTC 2013


On 07/03/13 at 09:25 +0100, Niels Thykier wrote:
> At the moment, UDD runs an update script about once every 3 hours (and a
> slightly more extensive run once a day)[1].  Optimally, we would have no
> delay at all - there are IRC bots that post the bugs within a minute or
> two of them being opened or closed[1].
> 
> It does not have to be UDD's bug view; if you can create a live updated
> bug view with good filtering on top of the Debian BTS that would be fine
> with me as well.  As long as the result is good for finding and
> squashing RC bugs or finding packages that are missing an unblock[2].
> 
> To get all the information in near real time (e.g the "Affects Wheezy"
> and "Affects sid" information), I guess that the BTS side /may/ need
> changes as well.
> 
> 
> I admit the idea is not well fleshed out or researched, so it may need a
> bit of work to mold it into a proper GSoC.  It would also need mentors
> that are actually familiar with UDD or/and the BTS on a development
> basis (my experience is limted to "user").

Hi,

I agree that not having live updates is suboptimal.

One problem is the BTS itself. The fact that it uses flat files as a DB
makes it really hard to query. Rewriting the BTS data storage as an SQL
DB would be a really nice GSOC project. We tried to setup such a project
last year, but failed to find mentors for that (with the required BTS
knowledge).

Then, the other problem is UDD. UDD currently reimports all bugs on a
regular basis, because it's easier to keep accurate data that way.
Turning it into live updates would be possible, but not trivial.  The
way the BTS bot works is that it monitors submitted bugs. But it does
not know anything about modified bugs, so doing it that way would not
work. Newly submitted bugs are easy to detect, modified bugs are much
harder, because the status of a bug can be modified:
- directly on the BTS
- through an archive change (package migrates -> change which releases
  it affects)

My plan would be to monitor BTS and archive changes using e.g. inotify.
That would be part of a rewrite of the core of UDD. I'm not very much
motivated about mentoring a student on that, unless it's a very good
student. (I plan to work on that myself at some point)

Lucas



More information about the Soc-coordination mailing list