Re: Google SoC - Bug Triaging and Forwarding Tool
On Wed, Mar 21, 2007, Gustavo R. Montesino wrote:
> Usually, these teams are running up against
> huge backlogs of bug reports, and some bugs may remain unanswared for
> a long period of time, which in turn may cause the reporting users to
> think their reports aren't useful, and stop to submit bugs.
> I'm a 21 years old Brazilian, and
> are currently on a Computer Science like course at Faculdade de
> Tecnologia de São Paulo (FATEC-SP), a somewhat famous public
> university on my state.
> * See the full bug report, including follow-ups and
> attachments/patches, for one of the bugs returned in the filter or an
> manually-entered bug number.
I would offer the possibility to spawn a web browser or mail client. I
personally best browse bugs in Mutt or in Galeon, and I expect
everybody is more confortable with his preferred client. This would be
> * Send a Followup message to a bug report
Hence, you might not need to implement this.
> * Search for similar bug reports in the upstream developer's BTS. If
> found, automatically tag the Debian bug properly.
This is a bit vague as it doesn't say whether the user of the tool is
giving the search information, or whether the information is extracted
automatically by the tool from the Debian bug.
> 5. Estimated Timeline
> * April - May: Study of the resources available to use in the project
> (Debian BTS SOAP/LDAP interface, Bugzilla interaction resources, etc)
> and design of the tool. Request needed unavaliable features, if any,
> with patches if possible.
There's a rsync interface to get a "summary" file for each bug which
might turn out to be the information you use from debbugs. HTTP would
be fragile and slow, SOAP will be slow, LDAP is not exactly in sync;
reportbug-ng is moving towards SOAP, but bts-link is based on Rsync. I
don't know which one of the two is best.
> 6. Deliverables
> * Debian package of said software.
Heh, nice to mention it!
The rest of your document was fine! Most of my points above are minor.