Re: Google SoC - Bug Triaging and Forwarding Tool
Please note I've kept some parts of the proposal deliberately generic,
as I won't have enough time to plan implementation details pefore the
application proposal deadline, and it's a bit hard to antecipate the
needed time to implement things without some study :(
Em Qua, 2007-03-21 às 14:20 +0100, Loïc Minier escreveu:
> On Wed, Mar 21, 2007, Gustavo R. Montesino wrote:
>
> > * 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
> like reportbug-ng.
I was thinking about launching the browser. Integrating it with MUAs
through the mboxes availiable on b.d.o seems like a nice idea also.
> > * Send a Followup message to a bug report
>
> Hence, you might not need to implement this.
It would be hopefully pretty easy to launch an MUA with the right
headers, so I don't see a good reason to not offer this on the btft
interface. It would be handy to people which prefer to see the bug
through the web interface.
> > * 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.
I would like the tool to do the search by itself, but I'm not yet sure
if I'll have time to implement this during the SoC, so I haven't added
this explicitly in the proposal. If I don't manage to do so during the
SoC, I'll code this later.
>
> > 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.
I've read something about putting these summaries in a SQL backend
somewhere recently also, and will look at that.
Ideally, I'd be able to know exactly what technologies I'll use and
discriminate this in the proposal, but unfortunately this won't be
possible; so I've added this "study time" on the proposal instead.
Thanks for the feedback.
Regards,
Gustavo R. Montesino
Reply to: