Gnus interface to Bugzilla?

Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Would it make sense to make a Gnus interface to Bugzilla?  Every bug
report could appear as a group, and then the responses would be the
messages.

One would have to create functions to respond/change bug report
status, too.

Does Bugzilla have a programmable interface, or does one have to parse
the HTML?
 
-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Does Bugzilla have a programmable interface, or does one have to parse
> the HTML?

Newer versions of Bugzilla allow setting the ctype={format} parameter,
så one can get out csv/xml/whatever data.

So parsing Bugzilla should be pretty easy.  However, the listing of
the bugs in question doesn't include how many responses there have
been, so you won't get the most important thing in a news reader --
notification that there are new messages to read.

Well, without actually querying each bug.

Which might not be out of the question.  I'd guess it's not uncommon
to only be interested in a small subset of the bug reports...  Hm...

So, how would this work?

You'd specify an nnbugzilla server with a handy command that says
which Bugzilla to use, and what components you want (and perhaps the
rest of the query criteria).  Fetching new news from this server would
be one buglist.cgi call, and one show_bug.cgi call per bug in this
list.

Entering a group would show you the report and the responses, of
course.

I think it's workable...

Then there's responding/changing state/adding Cc/and so on, which I
haven't looked into at all.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Steve Youngs]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

* Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  > Would it make sense to make a Gnus interface to Bugzilla?

Yes, it'd be cool.  We use Bugzilla at SXEmacs.org and just about all
of us use Gnus, so you have a ready made test dept. :-)

  > Every bug report could appear as a group, and then the responses
  > would be the messages.

No, that'd suck.  Each bug should be a thread within the group that is
the "product".  We have 2 "products" in our Bugzilla, so you'd have
something like...

  nnbugzilla:sxemacs.sxemacs
  nnbugzilla:sxemacs.web

Oh, in the Bugzilla contrib directory there is bug_email.pl which may
be of some value.

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                 I am Dyslexic of Borg.                   | 
|    Fusistance is retile. Your arse will be laminated.    |
|------------------------------------<steve@sxemacs.org>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Steve Youngs <steve@sxemacs.org> writes:

> No, that'd suck.  Each bug should be a thread within the group that is
> the "product".  We have 2 "products" in our Bugzilla, so you'd have
> something like...

Hm...  the problem then would be things like "I want to see all the
messages in bug #542, but not any others in the same product
category".  With the one-group-per-bug approach, that would be `C-u
RET', while with the one-group-per-product, it would require a
separate special command.  And if you're not interested in a bug, you
just kill the group.  Etc.

Of course, it helps if you use topics and all the new bugzilla groups
end up there automatically.

> Oh, in the Bugzilla contrib directory there is bug_email.pl which may
> be of some value.

I had a peek, and it parses email messages and then talks to the
database itself?  I think what Gnus needs is a way to construct a HTTP
POST so that it looks like a normal user web interaction...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Steve Youngs]

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

* Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  > Steve Youngs <steve@sxemacs.org> writes:
  >> No, that'd suck.  Each bug should be a thread within the group that is
  >> the "product".  We have 2 "products" in our Bugzilla, so you'd have
  >> something like...

  > Hm...  the problem then would be things like "I want to see all the
  > messages in bug #542, but not any others in the same product
  > category".  With the one-group-per-bug approach, that would be `C-u
  > RET', while with the one-group-per-product, it would require a
  > separate special command.

`/ s' solves that for one-group-per-product.

  > And if you're not interested in a bug, you just kill the group.
  > Etc.

one-group-per-product would just use scoring here.

  > Of course, it helps if you use topics and all the new bugzilla groups
  > end up there automatically.

Also helps if you hook the find-new-groups func into something so
these thousands of new groups appear automatically.

BTW, suppose I was a Mozilla developer... your one-group-per-bug means
I could have anywhere up to 300000 groups in my Gnus!!  That's just
insane.


-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                 I am Dyslexic of Borg.                   | 
|    Fusistance is retile. Your arse will be laminated.    |
|------------------------------------<steve@sxemacs.org>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Steve Youngs <steve@sxemacs.org> writes:

> `/ s' solves that for one-group-per-product.

But surely you wouldn't display all the responses to all the bugs in
the product normally?  `C-u g' on a product would pull in an awfully
large number of messages...

>   > And if you're not interested in a bug, you just kill the group.
>   > Etc.
>
> one-group-per-product would just use scoring here.

True, but you have the latency issue.  Selecting the messages is one
extra call to show_bugs.cgi.

> BTW, suppose I was a Mozilla developer... your one-group-per-bug means
> I could have anywhere up to 300000 groups in my Gnus!!  That's just
> insane.

No, you'd kill them off as you go along.  nnslashdot uses a
one-group-per-item approach, and that seems to work well.

There's also the dreaded "numbering issue".  You have to map bugzilla
comments to article numbers, and using a several-bugs-in-one-group is
a nightmare.  You'd have to keep such a mapping up to date locally,
which is brittle.  With one-group-one-bug, you just use the natural
numbering of the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Steve Youngs <steve@sxemacs.org> writes:

> your one-group-per-bug means I could have anywhere up to 300000
> groups in my Gnus!!

(It would also be outside the scope of what nnbugzilla could sensibly
do.  To support 300K bug reports, it would have to issue 300K
show_bug.cgi calls, no matter whether it uses one approach or the
other...) 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Sebastian Freundt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Steve Youngs <steve@sxemacs.org> writes:
>
>> `/ s' solves that for one-group-per-product.
>
> But surely you wouldn't display all the responses to all the bugs in
> the product normally?  `C-u g' on a product would pull in an awfully
> large number of messages...
>
>>   > And if you're not interested in a bug, you just kill the group.
>>   > Etc.
>>
>> one-group-per-product would just use scoring here.
>
> True, but you have the latency issue.  Selecting the messages is one
> extra call to show_bugs.cgi.
>
>> BTW, suppose I was a Mozilla developer... your one-group-per-bug means
>> I could have anywhere up to 300000 groups in my Gnus!!  That's just
>> insane.
>
> No, you'd kill them off as you go along.  nnslashdot uses a
> one-group-per-item approach, and that seems to work well.

Hm, the problems with the one-group-per-bug approach I see is that I can
hardly imagine anything when I read bugzilla_mozilla_org.firefox.bug498
Adding a description is no option either, it'll be a flood of weird stuff
in my Group buffer.

> There's also the dreaded "numbering issue".  You have to map bugzilla
> comments to article numbers, and using a several-bugs-in-one-group is
> a nightmare.  You'd have to keep such a mapping up to date locally,
> which is brittle.  With one-group-one-bug, you just use the natural
> numbering of the bug report.

You do not need to use the natural ordering of numbers, just use 
article# = bug# * 1000 + n, with n=0 for the original post and the n-th
comment otherwise.

How about making it customisable whether to use <site>.<product> groups or
<site>.<product>.<bug>?

Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEPmcblMmhrILJOQ4RAu2ZAJ9RuzU7Jyw99Z4hfqeXq0oQ5vGbnQCfRAJT
AUI4kAhEdVV8mhPQYjgIWec=
=YQhB
-----END PGP SIGNATURE-----

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Sebastian Freundt <hroptatyr@sxemacs.org> writes:

> Hm, the problems with the one-group-per-bug approach I see is that I can
> hardly imagine anything when I read bugzilla_mozilla_org.firefox.bug498
> Adding a description is no option either, it'll be a flood of weird stuff
> in my Group buffer.

The groups would have names corresponding to the title, like
nnslashdot groups.

       148: nnslashdot:Military Secrets for Sale on Stolen USB Drives (06/04/
        99: nnslashdot:AT&amp;T Seeks to Hide Spy Docs (06/04/13/1218237) 
       116: nnslashdot:Duke Nukem Forever Update (06/04/13/1233211) 
       241: nnslashdot:Fuel Cell Powered Japanese Trains on Trial in July (06

Of course, this leads to problems if the title changes...       
       
> You do not need to use the natural ordering of numbers, just use 
> article# = bug# * 1000 + n, with n=0 for the original post and the n-th
> comment otherwise.

The backends report lowest and highest articles in the groups.  So
each new bug would lead to Gnus saying that there are 1000 new
articles in the group.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Romain Francoise]

The one-group-per-bug approach is better and doesn't conflict with
one-group-per-product: you can just gather all bugs for one product into
one group with nnvirtual.

(That's how I solve the one-group-per-month vs. one-group-per-year
problem for mail archives: outgoing messages go into per-month groups,
and I gather them into several per-year nnvirtual groups, and one global
nnvirtual group.)

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Gnus interface to Bugzilla?

[Wes Hardaker]

>>>>> On Thu, 13 Apr 2006 10:47:35 +0200, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

Lars> Would it make sense to make a Gnus interface to Bugzilla?  Every
Lars> bug report could appear as a group, and then the responses would
Lars> be the messages.

Lars> One would have to create functions to respond/change bug report
Lars> status, too.

Lars> Does Bugzilla have a programmable interface, or does one have to parse
Lars> the HTML?

I actually started to write a nnsf plugin a while back that integrated
with SourceForge's bug database.  I found it quite cool and wanted to
finish it because I liked it better than the web interface.  But
sadly, I never did.

I actually had every bug appear as an article, and the entire article
would contain all the items...  Functionally the article would be
continually evolving.  I never really liked the zillions-of-groups
method of doing stuff.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Gnus interface to Bugzilla?

[Sebastian Freundt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Romain Francoise <romain@orebokech.com> writes:

> The one-group-per-bug approach is better and doesn't conflict with
> one-group-per-product: you can just gather all bugs for one product into
> one group with nnvirtual.
>
> (That's how I solve the one-group-per-month vs. one-group-per-year
> problem for mail archives: outgoing messages go into per-month groups,
> and I gather them into several per-year nnvirtual groups, and one global
> nnvirtual group.)

What's the regexp to gather them? For nnarchive groups based on a
date-stamp this is obvious to me. But what, like Lars suggest, groups look
like:
nnbugzilla:Again problems with this bugzilla backend

Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEPnuTlMmhrILJOQ4RAnJXAKCCqtUd9vElWKbzyW898k/9EM1wTACaA8d+
Omx5RuxWKtygKf9runmoEgQ=
=XQ5z
-----END PGP SIGNATURE-----

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Wes Hardaker <wes@hardakers.net> writes:

> I actually had every bug appear as an article, and the entire article
> would contain all the items...  Functionally the article would be
> continually evolving.  I never really liked the zillions-of-groups
> method of doing stuff.

Zillion-groups has its problems, but I think it would fit the way I
work, at least.  At my day job, we use Bugzilla quite actively to
discuss, well, bugs and stuff.  Knowing that somebody has written
something new about a bug that I'm interested in would most naturally
be displayed in the group buffer along with the rest of the
work-related stuff, I think.

Of course, a totally different approach would also be possible.  That
is, write an nntp server that talks directly with the Bugzilla
database and run it on the Bugzilla server.  Then it could output
stuff like how many responses there are to each bug report, which
would make response snappy, and it could maintain bug response/article
number mapping, thereby making it possible to have all the bug reports
in one group.

However, that requires a) that someone writes that, and b) you're able
to convince the Bugzilla admin that it's a good idea.

Perhaps something like that could be a part of the Bugzilla
distribution.  nntp.cgi.  :-)

Hm...  the more I think about this, the more I think that's the
correct approach to take.  That way all news readers (not just Gnus)
could use it...

On the other hand.  Hm.  Not sure.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Sebastian Freundt <hroptatyr@sxemacs.org> writes:

> What's the regexp to gather them? For nnarchive groups based on a
> date-stamp this is obvious to me. But what, like Lars suggest, groups look
> like:
> nnbugzilla:Again problems with this bugzilla backend

Well, it could be

nnbugzilla:Again problems with this bugzilla backend (Products, #456)

The category in parentheses, with the bug number added for
uniqueness.

One problem is what happens if a bug changes category...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Romain Francoise]

Sebastian Freundt <hroptatyr@sxemacs.org> writes:

> What's the regexp to gather them? For nnarchive groups based on a
> date-stamp this is obvious to me. But what, like Lars suggest, groups
> look like:
> nnbugzilla:Again problems with this bugzilla backend

In that case it's not possible of course, but if you name the group

nnbugzilla+foo:Again problems with this bugzilla backend

for your product foo, then it becomes possible.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

I've thought a bit more.  :-)

One typically (I think) use bugzilla with various filters.  I
typically just list the bugs that are assigned to me, and aren't
fixed/resolved/etc.

So presumably nnbugzilla would use the same query string as I would
use when I'm using a web browser to get the group (ie. bug) list.

But when a bug changes status to "fixed", then it would disappear from
the list returned by nnbugzilla, and Gnus would display it as a "*"'d
group (that is; a removed group).

Which is natural, but is it pretty?

The lots-of-bugs-in-one-group approach makes this less of an issue.
If the bug is closed, then it just doesn't appear in that group any
more.

Hm...
 
-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Perhaps something like that could be a part of the Bugzilla
> distribution.  nntp.cgi.  :-)
>
> Hm...  the more I think about this, the more I think that's the
> correct approach to take.  That way all news readers (not just Gnus)
> could use it...

Well, they couldn't.  The news reader has to supply the "search
criteria" used to get the relevant bugs.  So it might as well be a
cgi-bin script.

But it could output nntp data.  :-)  I kinda think the likelihood of
getting that into Bugzilla is pretty slim.

All Gnus needs is the number of responses per bug report, and that can
probably be put into buglist.cgi as it is...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Steve Youngs]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

* Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  > Of course, a totally different approach would also be possible.  That
  > is, write an nntp server that talks directly with the Bugzilla
  > database and run it on the Bugzilla server.

Oh, this is an _excellent_ idea!

  > However, that requires a) that someone writes that, and b) you're able
  > to convince the Bugzilla admin that it's a good idea.

I'm not sure I could be much help with `a', but for `b'... I'm
convinced already and will gladly install & test it here. :-)

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                 I am Dyslexic of Borg.                   | 
|    Fusistance is retile. Your arse will be laminated.    |
|------------------------------------<steve@sxemacs.org>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]

Re: Gnus interface to Bugzilla?

[Steve Youngs]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

* Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  > Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
  >> Perhaps something like that could be a part of the Bugzilla
  >> distribution.  nntp.cgi.  :-)
  >> 
  >> Hm...  the more I think about this, the more I think that's the
  >> correct approach to take.  That way all news readers (not just Gnus)
  >> could use it...

  > Well, they couldn't.  The news reader has to supply the "search
  > criteria" used to get the relevant bugs.  So it might as well be a
  > cgi-bin script.

Or a news article.

  Subject: search product=gnus owner=larsi state=open|new

with perhaps finer control in the body of the article for stuff like
keywords etc.


-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                 I am Dyslexic of Borg.                   | 
|    Fusistance is retile. Your arse will be laminated.    |
|------------------------------------<steve@sxemacs.org>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Steve Youngs <steve@sxemacs.org> writes:

>   > Well, they couldn't.  The news reader has to supply the "search
>   > criteria" used to get the relevant bugs.  So it might as well be a
>   > cgi-bin script.
>
> Or a news article.
>
>   Subject: search product=gnus owner=larsi state=open|new

You'd post a news article to the server to get the list of groups?
That's not very traditional.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> All Gnus needs is the number of responses per bug report, and that can
> probably be put into buglist.cgi as it is...

I've looked at the code.

It basically creates a select from the BUGS table.  That table doesn't
have a count of the number of responses, so you'd need to select from
the longdescs table.

Uhm...  you wouldn't happen to be working on this at the moment,
Steve?

http://issues.sxemacs.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=gnus

=>

DBD::Pg::st execute failed: ERROR:  syntax error at or near "desc" at character 1146
 [for Statement "SELECT bugs.bug_id, bugs.bug_severity, bugs.priority, bugs.bug_status, bugs.resolution, bugs.bug_severity, bugs.priority, bugs.rep_platform, map_assigned_to.login_name, bugs.bug_status, bugs.resolution, bugs.short_desc, (SUM(CASE WHEN (LOWER(longdescs_0.thetext) LIKE '%gnus%') THEN 1 ELSE 0 END)/COUNT(CASE WHEN (LOWER(longdescs_0.thetext) LIKE '%gnus%') THEN 1 ELSE 0 END) + CASE WHEN (LOWER(bugs.short_desc) LIKE '%gnus%') THEN 1 ELSE 0 END) AS relevance FROM bugs  INNER JOIN profiles AS map_assigned_to ON (bugs.assigned_to = map_assigned_to.userid) INNER JOIN longdescs AS longdescs_0 ON (bugs.bug_id = longdescs_0.bug_id ) LEFT JOIN bug_group_map  ON bug_group_map.bug_id = bugs.bug_id  WHERE ((bugs.bug_status IN ('UNCONFIRMED','NEW','ASSIGNED','REOPENED'))) AND (((CASE WHEN (LOWER(longdescs_0.thetext) LIKE '%gnus%') THEN 1 ELSE 0 END > 0) OR (bugs.short_desc ~* '(^|[^a-z0-9])gnus($|[^a-z0-9])'))) AND bugs.creation_ts IS NOT NULL AND ((bug_group_map.group_id IS NULL)) GROUP BY bugs.bug_id, bugs.short_desc, bugs.bug_severity, bugs.priority, bugs.bug_status, bugs.resolution, bugs.rep_platform, map_assigned_to.login_name, relevance desc ORDER BY relevance desc LIMIT 200"] at /var/www/htdocs/SXEmacs-issues/buglist.cgi line 820


-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Nelson Ferreira]

"Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars> Steve Youngs <steve@sxemacs.org> writes:
    >> No, that'd suck.  Each bug should be a thread within the group that is
    >> the "product".  We have 2 "products" in our Bugzilla, so you'd have
    >> something like...

    Lars> Hm...  the problem then would be things like "I want to see all the
    Lars> messages in bug #542, but not any others in the same product
    Lars> category".  With the one-group-per-bug approach, that would be `C-u
    Lars> RET', while with the one-group-per-product, it would require a
    Lars> separate special command.  And if you're not interested in a bug, you
    Lars> just kill the group.  Etc.

Why not 'overload' the concept of digest, i.e. treat the bug as a
digest and C-d would give you the replies there? If message-ids are
generated the read messages should still be marked as such right ?

    Lars> Of course, it helps if you use topics and all the new bugzilla groups
    Lars> end up there automatically.

I am not too fond of having groups created automatically, even with topics.


[...]


-- 
Nelson Ferreira

Re: Gnus interface to Bugzilla?

[Steve Youngs]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

* Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  > Uhm...  you wouldn't happen to be working on this at the moment,
  > Steve?

  > http://issues.sxemacs.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=gnus

  > =>

  > DBD::Pg::st execute failed: ERROR:  syntax error at or near "desc" at character 1146

I am now.  Or at least I will be after I've had some sleep.

erm, thanks for finding a bug in our bug tracker. :-)

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                 I am Dyslexic of Borg.                   | 
|    Fusistance is retile. Your arse will be laminated.    |
|------------------------------------<steve@sxemacs.org>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]

Re: Gnus interface to Bugzilla?

[Steve Youngs]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

* Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  > Steve Youngs <steve@sxemacs.org> writes:
  >> > Well, they couldn't.  The news reader has to supply the "search
  >> > criteria" used to get the relevant bugs.  So it might as well be a
  >> > cgi-bin script.
  >> 
  >> Or a news article.
  >> 
  >> Subject: search product=gnus owner=larsi state=open|new

  > You'd post a news article to the server to get the list of groups?
  > That's not very traditional.  :-)

You're still thinking group-per-bug... I'm in group-per-product mode. :-)

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                 I am Dyslexic of Borg.                   | 
|    Fusistance is retile. Your arse will be laminated.    |
|------------------------------------<steve@sxemacs.org>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]

Re: Gnus interface to Bugzilla?

[Romain Francoise]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Does Bugzilla have a programmable interface, or does one have to parse
> the HTML?

These days it exports data as RSS, so one can read bugs with nnrss.

As for the posting side, well, someone needs to write an email robot to
receive bug reports and submit them via HTTP.


/\_   <--- El Cheapo Solutions Expert hat
-R

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Steve Youngs <steve@sxemacs.org> writes:

>   >> Subject: search product=gnus owner=larsi state=open|new
>
>   > You'd post a news article to the server to get the list of groups?
>   > That's not very traditional.  :-)
>
> You're still thinking group-per-bug... I'm in group-per-product mode. :-)

Well, list of group, or list of bugs.  Still not very traditional.

Here are my thoughts before turning in for the night:

1) nnbugzilla will have to be reasonable fast for it to be used

2) Gnus needs article number counts for nnbugzilla to be interesting
   to use (I want to see whether there has been new discussion of a
   bug or bugs I'm watching)

3) There are many, many different versions of bugzilla out there, and
   none of the ones I have seen have commands that give us 2).
   Issuing one http call for each bug report in the active list means
   that 1) is impossible

Therefore, the only solution is to add a new, server-side mechanism,
nntp.cgi, which will (basically) output an active file.  It'll list
bug number, product, and short description, as well as the number of
responses it has had.

And then Gnus can do the rest on the client side.

So to use nnbugzilla, you will have to be, or know, the bugzilla
admin.  I can't see any other way to make this work.  Which is a bit
of a disappointment, because it would be nice to just be able to point
Gnus at a random Bugzilla repository and have it work.

I may be overlooking something, though.  :-)

Sleep now.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Wes Hardaker]

>>>>> On Thu, 13 Apr 2006 18:36:10 +0200, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

>> I actually had every bug appear as an article, and the entire article
>> would contain all the items...  Functionally the article would be
>> continually evolving.  I never really liked the zillions-of-groups
>> method of doing stuff.

Lars> Zillion-groups has its problems, but I think it would fit the way I
Lars> work, at least.

FYI, just to be complete as the discussion has long surpassed this
chain of thought, but I suddenly remembered what I really did in my
nnsf backend: I generated article numbers from the bug number in combo
with the response number.  That way I got a threaded summary buffer
(had to generate thread data too of course) with current open bugs in
it.  Auto-collapsing the tree made it neat and tidy.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Romain Francoise <romain@orebokech.com> writes:

> These days it exports data as RSS, so one can read bugs with nnrss.

I couldn't find anything mentioning RSS in the current Bugzilla
sources. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Nelson Ferreira <nelson.ferreira@ieee.org> writes:

> Why not 'overload' the concept of digest, i.e. treat the bug as a
> digest and C-d would give you the replies there? If message-ids are
> generated the read messages should still be marked as such right ?

It wouldn't tell me when new comments have been made.

Let's assume that nntp.cgi has been written, so that nnbugzilla can
get data out at a sensible speed.

One-group-per-search/product/category/whatever:

The user would have a command in the group buffer to create the group,
which would prompt for URL, category, etc, and then create the group
based on those criteria.

`M-g' on the group would issue one nntp.cgi call to get the bugs and
how many comments there have been made.  nnbugzilla would maintain a
`(bug# comment# article-number)' triplet in a local file to be able to
map article numbers to bug/comments.

Say there has been one new comment made to a bug.  `M-g' will report
one new article.  Entering the group with `RET' does one show_bug.cgi
call (because of the mapping it knows which bug the user wants to
see), and displays the single comment.

Hitting `^' will go to the previous comment without any http traffic,
because Gnus will already have all the headers for this bug, and
threading works.  `A T' will show all the comments in the bug.

If a bug disappears from the group, nnbugzilla removes all the
mappings for that bug.  Or perhaps using an expiry scheme -- dead bugs
that are older than a month are removed.

Neat, huh?

The only problem is that the only way to display all open bug reports
in the category is to `C-u RET' the group, and display all the threads
to all the bugs.  Which means issuing one show_bug.cgi per bug.  So
just getting displaying what bugs are active would be s.l.o.w.

I think one-group-per-category just can't be made workable because of
this last problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Romain Francoise]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I couldn't find anything mentioning RSS in the current Bugzilla
> sources.

How current are your sources?  I'm pretty sure 2.20 has it.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Romain Francoise <romain@orebokech.com> writes:

> How current are your sources?  I'm pretty sure 2.20 has it.

2.20.1...  Ah, I just didn't grep deeply enough into the tree.  Yes,
buglist.cgi has a ctype=rss format.  And interestingly enough, it has
some useful data not found in the other formats.  :-)

  <entry>
    <title>[Bug 119627] GridLayout - feedback does not allow dropping in all pla
ces</title>
    <link rel="alternate" type="text/html"
          href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=119627"/>
    <id>https://bugs.eclipse.org/bugs/show_bug.cgi?id=119627</id>
    <author>
      <name>Joe Winchester</name>
    </author>
    <updated>2005-12-08T15:10:16Z</updated> 
    <summary type="html">

The interesting item here being <updated>.  With this field,
nnbugzilla should be able to keep track of which bug reports have
been, er, updated, and issue a show_bug.cgi call for those that have
been updated.

No need for the proposed nntp.cgi program.

(Of course, the first time you use nnbugzilla, it will take quite a
long time, but each subsequent `g' will only issue one buglist.cgi
call.  (Plus extra calls for each bug that has been updated, but
that'll happen quite rarely in comparison.))

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Nelson Ferreira]

"Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars> Nelson Ferreira <nelson.ferreira@ieee.org> writes:

[...]

Understood your reasoning on why digests would not be a good match.

    Lars> The only problem is that the only way to display all open bug
    Lars> reports in the category is to `C-u RET' the group, and display
    Lars> all the threads to all the bugs.  Which means issuing one
    Lars> show_bug.cgi per bug.  So just getting displaying what bugs
    Lars> are active would be s.l.o.w.

    Lars> I think one-group-per-category just can't be made workable
    Lars> because of this last problem.

I'm sure there must be some cgi in Bugzilla one could issue that kind
of search with the right set of fields for you to be able to generate
at least the summary and defer the retrieval of the body when the
article is selected?


[...]


-- 
Nelson Ferreira

Re: Gnus interface to Bugzilla?

[Lars Magne Ingebrigtsen]

Nelson Ferreira <nelson.ferreira@ieee.org> writes:

> I'm sure there must be some cgi in Bugzilla one could issue that kind
> of search with the right set of fields for you to be able to generate
> at least the summary and defer the retrieval of the body when the
> article is selected?

Oh, that's not the problem.  nnbugzilla knows what the bugs are.  The
problem is a Gnus UI one.  How does the user say "show me what bug
reports exist" as opposed to "let me read a report/some bug reports
and comments".

Which is why I think the many-bugs-in-one-group idea doesn't work.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus interface to Bugzilla?

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> One typically (I think) use bugzilla with various filters.  I
> typically just list the bugs that are assigned to me, and aren't
> fixed/resolved/etc.

That's one thing I do.

Other things, are:
 - Go to a particular bug with a bug number (typically revisiting an
   old fixed bug for some reason)
 - Search through all bugs for a text (typically when looking for
   existing reports for an encountered problem)
 - Browse through open problems for a particular product and category
   (typically when assessing what should be done before a release)

Re: Gnus interface to Bugzilla?

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> No need for the proposed nntp.cgi program.

Is there a need for nnbugzilla?  Or can nnrss be used directly in any
useful way?