Debbugs testbed

Debbugs testbed

[Nick Roberts]

I'm trying to browse the bug databse at:

    http://emacsbugs.donarmstrong.com/

but keep getting messages like:

    The requested URL /release-critical/ was not found on this server.

or

    You don't have permission to access /cgi-bin/pkgindex.cgi on this server.

etc, if I try to follow links under Supplementary information:

    The current list of Release Critical Bugs.

    ...

    The following bug report indices are available:

        * Packages with active and archived bug reports.
        * Source packages with active and archived bug reports.
        * Maintainers of packages with active and archived bug reports.
        * Submitters of active and archived bug reports.

Any tips about how I should browse the database?

I'm presuming now if I send my previous reports using report-emacs-bug that
they will end up in the database.  Is that right?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Debbugs testbed

[Don Armstrong]

On Fri, 29 Feb 2008, Nick Roberts wrote:
> Any tips about how I should browse the database?
> 
> I'm presuming now if I send my previous reports using report-emacs-bug that
> they will end up in the database.  Is that right?

http://emacsbugs.donarmstrong.com/emacs is probably the most useful thing.

pkgindex.cgi is disabled because in Debian it's totally useless,[1]
but I can enable it for emacs.

The 'release-critical' url is also specific to Debian, but what
usually is present there can also be set up for emacs once the
maintainers decide what bugs qualify as release critical. ;-)


Don Armstrong

1: At last count there are nearly 77000 bugs open
-- 
Quite the contrary; they *love* collateral damage. If they can make
you miserable enough, maybe you'll stop using email entirely. Once
enough people do that, then there'll be no legitimate reason left for
anyone to run an SMTP server, and the spam problem will be solved.
 -- Craig Dickson in <20020909231134.GA18917@linux700.localnet>

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Debbugs testbed

[Stefan Monnier]

>> Any tips about how I should browse the database?

> http://emacsbugs.donarmstrong.com/emacs is probably the most useful thing.

> pkgindex.cgi is disabled because in Debian it's totally useless,[1]
> but I can enable it for emacs.

Yes, that would be good.  I've used the "index packages" command, but it
would make sense to have it available from the web page as well.

> The 'release-critical' url is also specific to Debian, but what
> usually is present there can also be set up for emacs once the
> maintainers decide what bugs qualify as release critical. ;-)

That might indeed be helpful.  Tho I'm not sure how that would work.
E.g. how can I specify that it's release-critical for Emacs-22.2 rather
than release-critical for Emacs-23.1?

>> I'm presuming now if I send my previous reports using report-emacs-bug that
>> they will end up in the database.  Is that right?

I believe this is not yet the case.  Don?


        Stefan

Re: Debbugs testbed

[Bill Wohler]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The 'release-critical' url is also specific to Debian, but what
>> usually is present there can also be set up for emacs once the
>> maintainers decide what bugs qualify as release critical. ;-)
>
> That might indeed be helpful.  Tho I'm not sure how that would work.
> E.g. how can I specify that it's release-critical for Emacs-22.2 rather
> than release-critical for Emacs-23.1?

severity grave
tags bug# 22.2
thanks

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Debbugs testbed

[Don Armstrong]

On Thu, 28 Feb 2008, Stefan Monnier wrote:
> Yes, that would be good. I've used the "index packages" command, but
> it would make sense to have it available from the web page as well.

I've renabled it. (I used the default apache configuration which
denies it from most hosts.)
 
> > The 'release-critical' url is also specific to Debian, but what
> > usually is present there can also be set up for emacs once the
> > maintainers decide what bugs qualify as release critical. ;-)
> 
> That might indeed be helpful. Tho I'm not sure how that would work.
> E.g. how can I specify that it's release-critical for Emacs-22.2
> rather than release-critical for Emacs-23.1?

The way this is typically done is by severity+versioning.

So bugs of severity > than a certain level are release critical; you
can indicate whether a bug is fixed or not in a particular version
using the version tracking. [That is, you would either close the bug
with a Version pseudoheader, or use fixed foobug fooversion; in a
command to control.]

Then, assuming the BTS knows what version of the 22 series 23.1 is a
decendant of, bugs that are fixed there are automatically marked fixed
in all decendants of that version, but are still marked buggy all
decendants of an unfixed version (and unknown in all other versions.)
[It may be worthwhile to tie this to VCS versions, but the code to do
that integration isn't there.[1]]

You can see the graphs of what I'm talking about for a semi-complex
package in Debian here:

http://tinyurl.com/2mtud7 [2]

> >> I'm presuming now if I send my previous reports using
> >> report-emacs-bug that they will end up in the database. Is that
> >> right?
> 
> I believe this is not yet the case. Don?

AFAICT, that's not yet the case. It's basically waiting for one of the
mail administrators to put in the hook to send bugs, or for me to do
it manually.


Don Armstrong

1: And I would really need to think out what the right method of
handling the correspondance between a VCS version and a release
version.

2: http://bugs.debian.org/cgi-bin/version.cgi?info=1;width=;found=21.3%2B1-5;found=21.3%2B1-8;found=emacs21%2F21.4a-3;height=;package=emacs21;format=png;collapse=1;ignore_boring=0
-- 
Taxes are not levied for the benefit of the taxed.
 -- Robert Heinlein _Time Enough For Love_ p250

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Debbugs testbed

[Stefan Monnier]

>> Yes, that would be good. I've used the "index packages" command, but
>> it would make sense to have it available from the web page as well.

> I've renabled it. (I used the default apache configuration which
> denies it from most hosts.)

Thank you.

> So bugs of severity > than a certain level are release critical; you
> can indicate whether a bug is fixed or not in a particular version
> using the version tracking. [That is, you would either close the bug
> with a Version pseudoheader, or use fixed foobug fooversion; in a
> command to control.]

Makes sense.

> Then, assuming the BTS knows what version of the 22 series 23.1 is a
> decendant of, bugs that are fixed there are automatically marked fixed
> in all decendants of that version, but are still marked buggy all
> decendants of an unfixed version (and unknown in all other versions.)
> [It may be worthwhile to tie this to VCS versions, but the code to do
> that integration isn't there.[1]]

How can we tell Debbugs about the version-graph?

>> >> I'm presuming now if I send my previous reports using
>> >> report-emacs-bug that they will end up in the database. Is that
>> >> right?
>> I believe this is not yet the case. Don?
> AFAICT, that's not yet the case. It's basically waiting for one of the
> mail administrators to put in the hook to send bugs, or for me to do
> it manually.

Have you heard from the mail administrators?  Maybe we can do it
manually for now?


        Stefan

Debbugs testbed

[Don Armstrong]

I've configured a testbed of debbugs that can be used. There currently
is one package configured (emacs), and a temporary mailing list,
emacsbugs@lists.donarmstrong.com is set as the maintainer. [You can
browse its archives at
http://lists.donarmstrong.com/pipermail/emacsbugs/ or subscribe at
http://lists.donarmstrong.com/mailman/listinfo/emacsbugs .]

The web interface is currently here:

http://emacsbugs.donarmstrong.com

Useful links to start are http://emacsbugs.donarmstrong.com/emacs and
http://emacsbugs.donarmstrong.com/Reporting

You can submit new bugs to test using
submit@emacsbugs.donarmstrong.com, and you can play with the control
interface as usual using control@emacsbugs.debian.org.

[You'll have to ignore any Debian specific branding that's in the
documentation, as the most accurate, most up-to-date documentation
doesn't have the automatic branding hooks.]

If you've got specific questions, feel free to ask me via e-mail, or
you can usually catch me on OFTC and FN under the nick 'dondelelcaro'.
[#debian-debbugs on OFTC is the debbugs upstream channel.]


Don Armstrong

-- 
Grimble left his mother in the food store and went to the launderette
and watched the clothes go round. It was a bit like colour television
only with less plot.
 -- Clement Freud _Grimble_

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Debbugs testbed

[Óscar Fuentes]

Don Armstrong <don@donarmstrong.com> writes:

> I've configured a testbed of debbugs that can be used. There currently
> is one package configured (emacs), and a temporary mailing list,
> emacsbugs@lists.donarmstrong.com is set as the maintainer. [You can
> browse its archives at
> http://lists.donarmstrong.com/pipermail/emacsbugs/ or subscribe at
> http://lists.donarmstrong.com/mailman/listinfo/emacsbugs .]
>
> The web interface is currently here:
>
> http://emacsbugs.donarmstrong.com
>
> Useful links to start are http://emacsbugs.donarmstrong.com/emacs and
> http://emacsbugs.donarmstrong.com/Reporting

As mentioned on the discussion last month, debbugs has some drawbacks:

First: it has no web interface for filling bugs: an easy and intuitive
interface for users is paramount.

Second: IMO, it is complex. Look at what you are expected to read just
for sending a bug:

http://emacsbugs.donarmstrong.com/Reporting 

See the interface for querying the bug database:

http://emacsbugs.donarmstrong.com/

and after all that those checkboxes you can't ask simple things like
"bugs reported for Emacs v 22.1 or later".

Third: Ironically, the mail message containing the bug report has a
simple format, once you know the component (package, on debian parlance)
and version. But this is not easy to do. `cc-mode' is not the same as
`c-mode', and `auctex' is not under the Emacs project. A web interface
can show a list of known components for the user to pick.

Fourth: Even if `report-emacs-bug' is changed to accomodate debbugs'
requirements, it will affect to future Emacs relases only, so bugs
submitted by people with the old implementation would require special
treatment. My experience shows that it is vital to treat all bugs
equally. It should be one and only one place where to look for bug
reports, although it can have several interfaces.

To recap: even if debbugs can look good to rms and hackers sharing a
similar culture (such as those that abound on Debian) it isn't as
effective as it could be for interfacing with Emacs users nor for easing
the job of the developers that processes bug reports. IMNSHO.

[snip]

-- 
Oscar

Re: Debbugs testbed

[Nick Roberts]

 > > Useful links to start are http://emacsbugs.donarmstrong.com/emacs and
 > > http://emacsbugs.donarmstrong.com/Reporting
 > 
 > As mentioned on the discussion last month, debbugs has some drawbacks:
 >...

What I like about it is that Don has gone and done something rather than just
sitting back and talking about it.  Let's wait until people have tried it out
before discussing it further.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Debbugs testbed

[Óscar Fuentes]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > > Useful links to start are http://emacsbugs.donarmstrong.com/emacs and
>  > > http://emacsbugs.donarmstrong.com/Reporting
>  > 
>  > As mentioned on the discussion last month, debbugs has some drawbacks:
>  >...
>
> What I like about it is that Don has gone and done something rather than just
> sitting back and talking about it.  Let's wait until people have tried it out
> before discussing it further.

I'm sorry. Forgot to ask your permission for commenting. <g>.

For testing debbugs (or any other bug tracker) it is not enough with the
developers. You need to involve the users.

debbugs is not new, it is the system used by Debian and there is plenty
of experience with it.

Plus, some things are obvious. You don't need to work with debbugs for 6
months to realize that it is has no web interface for reporting bugs.

Not do dismiss Don's work. I appreciate his effort.

-- 
Oscar

Re: Debbugs testbed

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> First: it has no web interface for filling bugs: an easy and intuitive
> interface for users is paramount.

I expect an _Emacs_ interface for filing bugs is far, far, more
important in this case....

[An interface being "web" or not has absolutely nothing to do with it's
being "easy" -- look at the original bugzilla, which was as web-centric
as they come, and yet had one of the most horrid and newbie-hostile
bug-filing (and searching) interfaces ever...]

-Miles

-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that
            will  make every christian in the world foamm at the mouth?
[iddt]      nurg, that's the goal

Re: Debbugs testbed

[Óscar Fuentes]

Miles Bader <miles.bader@necel.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>> First: it has no web interface for filling bugs: an easy and intuitive
>> interface for users is paramount.
>
> I expect an _Emacs_ interface for filing bugs is far, far, more
> important in this case....

An Emacs interface would be great, but you still need a fall-back
interface for when the bug or the environment blocks the operation of
the Emacs interface.

> [An interface being "web" or not has absolutely nothing to do with it's
> being "easy" -- look at the original bugzilla, which was as web-centric
> as they come, and yet had one of the most horrid and newbie-hostile
> bug-filing (and searching) interfaces ever...]

There are plenty of bad examples for everything, even for Emacs
interfaces :-)

Emacs-based of web-based, such an interface can do smart things that
brings a friendlier experience than a plain-text e-mail system does. (Of
course an Emacs-based interface is much better because it can
automatically provide lots of information by introspection.)

-- 
Oscar

Re: Debbugs testbed

[Don Armstrong]

On Wed, 20 Feb 2008, Óscar Fuentes wrote:
> First: it has no web interface for filling bugs: an easy and
> intuitive interface for users is paramount.

One of the summer of code projects for 2007 was to create one, and it
does work. Secondly, it's not like it would be all that difficult for
someone to create one either; all it needs to do is take a list of
"components", and gate the program field to e-mail and send it to
submit@. [The sumer of code project does way more, including modifying
the status of bugs.]

> Second: IMO, it is complex. Look at what you are expected to read
> just for sending a bug:
> 
> http://emacsbugs.donarmstrong.com/Reporting

We generally suggest that people use reportbug to do it, and it
wouldn't be all that difficult to handle dealing with submissions that
didn't fit that format by assigning them to a general package. [The
reason why Debian doesn't is because typically bugs filed by people
who are unable to follow those instructions or run reportbug tend to
be useless.]

> See the interface for querying the bug database:
> 
> http://emacsbugs.donarmstrong.com/
> 
> and after all that those checkboxes you can't ask simple things like
> "bugs reported for Emacs v 22.1 or later".

You actually can, but it requires knowing how to generate the urls
manually. That's actually one of the next things to improve on my todo
list, as that selection form is nearly useless.[1]

For example, in Debian you'd be looking at something like:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=emacs22;version=22.1%2B1-1

which would tell you about the bugs which are known to affect version
22.1+1-1 of the emacs22 package.

> Third: Ironically, the mail message containing the bug report has a
> simple format, once you know the component (package, on debian
> parlance) and version. But this is not easy to do. `cc-mode' is not
> the same as `c-mode', and `auctex' is not under the Emacs project. A
> web interface can show a list of known components for the user to
> pick.

Sure, but it's not a big deal even if users don't know the component.
Debian has a 'general' pseudopackage for precisely this reason.
Developers who know better simply send a message to reassign the bug
to the proper component. (Users who don't know the components already
will almost invariably get them wrong anyway.)

In any event, it's entirely up to you all to figure out whether what
debbugs does or doesn't do will work for you, and if you decide to use
it, what changes are needed to make it optimal.


Don Armstrong

1: Patches are always accepted, the bzr is here:
http://bugs.debian.org/debbugs-source/
-- 
Any excuse will serve a tyrant.
 -- Aesop

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Debbugs testbed

[Tassilo Horn]

Óscar Fuentes <ofv@wanadoo.es> writes:

Hi Óscar,

> First: it has no web interface for filling bugs: an easy and intuitive
> interface for users is paramount.

Reading through http://emacsbugs.donarmstrong.com/Reporting I don't see
any reason that would hinder us to setup a simple web page for filing
bug reports with a browser.

The same applies to creating an emacs interface.

> Second: IMO, it is complex. Look at what you are expected to read just
> for sending a bug:
>
> http://emacsbugs.donarmstrong.com/Reporting 

I disagree.  The page explains in length what you should consider when
writing a bug report at all, the package, its version, a descriptive
subject, how to assign the bug to the correct component, etc.

If you specify these informations on a web page or you have to write
some pseudo headers in your mail makes no such big difference.

Bye,
Tassilo

Re: Debbugs testbed

[Mathias Dahl]

> Reading through http://emacsbugs.donarmstrong.com/Reporting I don't see
> any reason that would hinder us to setup a simple web page for filing
> bug reports with a browser.

I agree fully. It seems trivial to make a web interface that either 1)
sends e-mails in the background or 2) which access the database
directly. At least 1 would be really easy.

About the complexity of the instructions, it does not need to be like
that, we could show an example e-mail first and then explain the
options below for those who want to know in more detail or use more
advanced pseudo headers.

Re: Debbugs testbed

[Walter Franzini]

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

"Mathias Dahl" <mathias.dahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

[...]

> About the complexity of the instructions, it does not need to be like
> that, we could show an example e-mail first and then explain the
> options below for those who want to know in more detail or use more
> advanced pseudo headers.

Debian has the debian-el package that contain debian-bug: an Emacs
command to submit a bug report.

I think emacs hackers should not find it difficult to make debian-bug
become emacs-bug :-)

The only drawback I can see it that it assume you are using Emacs to
send/read email.

-- 
Walter Franzini
http://aegis.stepbuild.org/

PGP Public key ID: 1024D/CB3FEB43
Key fingerprint  : FA26 C33B CAFF 7848 EFEB  7327 96AA 2D57 CB3F EB43
Key server       : http://www.keyserver.net

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

Re: Debbugs testbed

[Xavier Maillard]

Hi,

   The only drawback I can see it that it assume you are using Emacs to
   send/read email.

Hum, currently, M-x report-emacs-bug is also using GNU Emacs
iternals to send an email. There is no need to read your email
into GNU Emacs to be able to report a bug (hopefully).

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Debbugs testbed

[Walter Franzini]

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

Xavier Maillard <xma-mXXj517/zsQ@public.gmane.org> writes:

> Hi,
>
>    The only drawback I can see it that it assume you are using Emacs to
>    send/read email.
>
> Hum, currently, M-x report-emacs-bug is also using GNU Emacs
> iternals to send an email. There is no need to read your email
> into GNU Emacs to be able to report a bug (hopefully).

In order to send email (not this one) I need to configure smtpmail to
use a specific server, port and enable starttls with not empty
credentials.  Maybe I'm not the only one.

I think that the default Emacs beahviour is not, and can't be, enough
to cope with policies that you find in a corporate network.

-- 
Walter Franzini
http://aegis.stepbuild.org/

PGP Public key ID: 1024D/CB3FEB43
Key fingerprint  : FA26 C33B CAFF 7848 EFEB  7327 96AA 2D57 CB3F EB43
Key server       : http://www.keyserver.net

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

Re: Debbugs testbed

[Richard Stallman]

    In order to send email (not this one) I need to configure smtpmail to
    use a specific server, port and enable starttls with not empty
    credentials.  Maybe I'm not the only one.

Could you explain what this has to do with the issue of using
Debbugs for Emacs maintenance?  I do not see any connection.

    I think that the default Emacs beahviour is not, and can't be, enough
    to cope with policies that you find in a corporate network.

"Default Emacs behavior" of what operation?

Re: Debbugs testbed

[Xavier Maillard]

   Xavier Maillard <xma@gnu.org> writes:

   >    The only drawback I can see it that it assume you are using Emacs to
   >    send/read email.
   >
   > Hum, currently, M-x report-emacs-bug is also using GNU Emacs
   > iternals to send an email. There is no need to read your email
   > into GNU Emacs to be able to report a bug (hopefully).

   In order to send email (not this one) I need to configure smtpmail to
   use a specific server, port and enable starttls with not empty
   credentials.  Maybe I'm not the only one.

   I think that the default Emacs beahviour is not, and can't be, enough
   to cope with policies that you find in a corporate network.

AFAIK, it will use the default sendmail command thus there is no
need to setup anything but your local MTA, won't it ? Anyway, we
have always used M-x r-e-b RET and it has neer turned out to be a
major problem for the users.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Debbugs testbed

[Don Armstrong]

On Fri, 22 Feb 2008, Xavier Maillard wrote:
> AFAIK, it will use the default sendmail command thus there is no
> need to setup anything but your local MTA, won't it ?

Right. In Debian, the reportbug tool actually defaults to send mail
directly to the BTS, and doesn't even require your local MTA to be set
up. Whatever machine ends up being the final location can have an MTA
running on 587 (submission) as well as 25 to avoid outgoing smtp
filtering too.


Don Armstrong

-- 
[A] theory is falsifiable [(and therefore scientific) only] if the
class of its potential falsifiers is not empty.
 -- Sir Karl Popper _The Logic of Scientific Discovery_ §21

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Debbugs testbed

[Xavier Maillard]

   On Fri, 22 Feb 2008, Xavier Maillard wrote:
   > AFAIK, it will use the default sendmail command thus there is no
   > need to setup anything but your local MTA, won't it ?

   Right. In Debian, the reportbug tool actually defaults to send mail
   directly to the BTS, and doesn't even require your local MTA to be set
   up. Whatever machine ends up being the final location can have an MTA
   running on 587 (submission) as well as 25 to avoid outgoing smtp
   filtering too.

Thank you for the clarification ;)

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Debbugs testbed

[Óscar Fuentes]

Tassilo Horn <tassilo@member.fsf.org> writes:

>> First: it has no web interface for filling bugs: an easy and intuitive
>> interface for users is paramount.
>
> Reading through http://emacsbugs.donarmstrong.com/Reporting I don't see
> any reason that would hinder us to setup a simple web page for filing
> bug reports with a browser.

I'm afraid that the web interface is more complex than what you
think. Its list of components, versions, maintainers, etc. must be in
sync with those that emacs uses, and this creates some nasty maintenance
work.

> The same applies to creating an emacs interface.
>
>> Second: IMO, it is complex. Look at what you are expected to read just
>> for sending a bug:
>>
>> http://emacsbugs.donarmstrong.com/Reporting 
>
> I disagree.  The page explains in length what you should consider when
> writing a bug report at all, the package, its version, a descriptive
> subject, how to assign the bug to the correct component, etc.

It must explain this because there are no intuitive guides. On a web
form (or a sophiticated Emacs form) there are a series of visible fields
that you are expected to fill, plus you can put checks to ensure that
the user fills all required information. If you have not this, you need
to resort to lengthy descriptions as those mentioned above.

> If you specify these informations on a web page or you have to write
> some pseudo headers in your mail makes no such big difference.

No need for such lengthy explanations on a decent web form. Take a look
at

http://trac.edgewall.org/newticket

and please tell me what is not clear to you (and that is a complex
incarnation of the Trac system).

-- 
Oscar

Re: Debbugs testbed

[Jason Rumney]

Óscar Fuentes wrote:
> I'm afraid that the web interface is more complex than what you
> think. Its list of components, versions, maintainers, etc. must be in
> sync with those that emacs uses, and this creates some nasty maintenance
> work.
>   
Only if its done as a static webpage (which unfortunately the existing 
web interface seems to be).

If it is designed from the start to get that information from the 
database, then there will be no need to update it to keep it in sync.

Re: Debbugs testbed

[Stefan Monnier]

>> I disagree.  The page explains in length what you should consider when
>> writing a bug report at all, the package, its version, a descriptive
>> subject, how to assign the bug to the correct component, etc.

> It must explain this because there are no intuitive guides. On a web
> form (or a sophiticated Emacs form) there are a series of visible fields
> that you are expected to fill, plus you can put checks to ensure that
> the user fills all required information. If you have not this, you need
> to resort to lengthy descriptions as those mentioned above.

IOW, your complaint about http://emacsbugs.donarmstrong.com/Reporting is
just a repeat of your complaint that there's no web-form to file a bug.

So many bikesheds, so little time,


        Stefan

Re: Debbugs testbed

[Manoj Srivastava]

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

On Wed, 20 Feb 2008 10:09:48 +0100, Tassilo Horn <tassilo@member.fsf.org> said: 

> Óscar Fuentes <ofv@wanadoo.es> writes: Hi Óscar,

>> First: it has no web interface for filling bugs: an easy and
>> intuitive interface for users is paramount.

> Reading through http://emacsbugs.donarmstrong.com/Reporting I don't
> see any reason that would hinder us to setup a simple web page for
> filing bug reports with a browser.

> The same applies to creating an emacs interface.

        For Debian, there already is an emacs interface to send in bug
 reports, debian-bug, based on reportbug.

;; Useful commands provided by this mode:
;;
;; debian-bug         - submit a bug report concerning a Debian package
;; debian-bug-web-bug - view a bug report on a web browser (via browse-url)
;; debian-bug-wnpp    - submit a Work Needed on Prospective Package bug report
;; debian-bug-request-for-package
;;                    - shortcut for a WNPP bug type.
;; debian-bug-ITP     - shortcut for a WNPP bug type
;;
;; debian-bug depends on either the bug package or the reportbug (>1.21)
;; package for best results.

        reportbug collects information not only from the local system,
 but from the BTS itself, but perhaps we can pull in the functionality
 into elisp. 

        manoj


[-- Attachment #2: debian-bug.el --]
[-- Type: application/emacs-lisp, Size: 88149 bytes --]

[-- Attachment #3: Type: text/plain, Size: 327 bytes --]



-- 
"I have come up with a sure-fire concept for a hit television show,
which would be called `A Live Celebrity Gets Eaten by a Shark'." -- Dave
Barry, "The Wonders of Sharks on TV"
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Debbugs testbed

[Richard Stallman]

    First: it has no web interface for filling bugs: an easy and intuitive
    interface for users is paramount.

We ask users to report bugs by email.  If we don't change that,
it is no loss.

    Third: Ironically, the mail message containing the bug report has a
    simple format, once you know the component (package, on debian parlance)
    and version. But this is not easy to do. `cc-mode' is not the same as
    `c-mode',

I think we will treat Emacs as one single project.

	      and `auctex' is not under the Emacs project.

If someone reports a bug in auctex we will forward it, I suppose.

    Fourth: Even if `report-emacs-bug' is changed to accomodate debbugs'
    requirements, it will affect to future Emacs relases only, so bugs
    submitted by people with the old implementation would require special
    treatment.

Could a script deal with this?

Re: Debbugs testbed

[Stephen J. Turnbull]

Richard Stallman writes:

 > I think we will treat Emacs as one single project [in the tracker].

You probably should not even think about this until people have
started working with the tracker.  True, the extreme modularity of
thousands of nearly independent Debian packages will not apply to
Emacs.  On the other hand, a simple set of components like "core",
"applications", "build", "docs", "services" (eg, mailing lists, web
site, code repositories, and the tracker itself) almost surely does.
Even that much will be useful in filtering and grouping issues.

There are a number of useful things that the backend can do
automatically with an appropriate classification scheme (eg, notify
upstream projects like AUCTeX and Gnus, or offstream projects like
VM), as well as enabling developers looking for a task to quickly
screen out many issues they don't want to see.

It is very important for users to be able to effectively search the
database for similar issues; this allows them to take the burden of
"cleaning" the database of duplicates off the developers.  Not all
will, but enough to make a difference.  Having a component
classification that approximates that of a "naive" user greatly
facilitates this.

Re: Debbugs testbed

[Thien-Thi Nguyen]

() Don Armstrong <don@donarmstrong.com>
() Tue, 19 Feb 2008 18:18:27 -0800

   http://emacsbugs.donarmstrong.com/Reporting

Here is a command that you can add directly to that page.

(defun debbugs-report-emacs-bug ()
  "Report an emacs bug using the debbugs testbed."
  (interactive)
  (let* ((testbed "submit@emacsbugs.donarmstrong.com")
         (report-emacs-bug-pretest-address testbed)
         (report-emacs-bug-address testbed))
    (call-interactively 'report-emacs-bug))
  (save-excursion
    (mail-subject)
    (beginning-of-line)
    (looking-at "Subject: \\([^;]+\\);")
    (let ((given (match-string 1)))
      (mail-text)
      (insert "Package: GNU Emacs\n"
              "Version: " given "\n"))))

thi

Re: Debbugs testbed

[Xavier Maillard]

   Here is a command that you can add directly to that page.

Perfect as a starter but if we go with debbugs, then we would
probably need a "revised" version of the debian-bug.el package.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Debbugs testbed

[Richard Stallman]

    I've configured a testbed of debbugs that can be used. There currently
    is one package configured (emacs), and a temporary mailing list,
    emacsbugs@lists.donarmstrong.com is set as the maintainer.

To make this a real test, we need to arrange to get all bug reports
into it.  That can be done by humans, or automatically (if that proves
feasible).  Can you write a script to process the messages sent by
M-x report-emacs-bug and put them in automatically?

Re: Debbugs testbed

[Don Armstrong]

On Wed, 20 Feb 2008, Richard Stallman wrote:
>     I've configured a testbed of debbugs that can be used. There currently
>     is one package configured (emacs), and a temporary mailing list,
>     emacsbugs@lists.donarmstrong.com is set as the maintainer.
> 
> To make this a real test, we need to arrange to get all bug reports
> into it.  That can be done by humans, or automatically (if that proves
> feasible).  Can you write a script to process the messages sent by
> M-x report-emacs-bug and put them in automatically?

If someone can bounce me one of these reports, it's no problem. [Once
I've got the code, we can arrange to Cc: from wherever the reports are
going now to an address @emacsbugs.donarmstrong.com or similar.]


Don Armstrong

-- 
Dropping non-free would set us back at least, what, 300 packages? It'd
take MONTHS to make up the difference, and meanwhile Debian users will
be fleeing to SLACKWARE.

And what about SHAREHOLDER VALUE? 
 -- Matt Zimmerman in <gYuD3D.A.ayC.nGB39@murphy>

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Debbugs testbed

[Stefan Monnier]

> I've configured a testbed of debbugs that can be used.  There currently
> is one package configured (emacs), and a temporary mailing list,
> emacsbugs@lists.donarmstrong.com is set as the maintainer.  [You can
> browse its archives at
> http://lists.donarmstrong.com/pipermail/emacsbugs/ or subscribe at
> http://lists.donarmstrong.com/mailman/listinfo/emacsbugs .]

> The web interface is currently here:

> http://emacsbugs.donarmstrong.com

Thank you very much for that.

I see it needs some general search&replace (it refers the user to
bugs.debian.org, packages.debian.org, and things like that).
But that'll do fine for testing.

I guess all that we need is a script somewhere that will read the bug
reports we receive on bug-gnu-emacs@gnu.org and
emacs-pretest-bug@gnu.org, extract all the info we can from them,
reformat them to fit debbugs's needs, and send them to
emacsbugs@lists.donarmstrong.com, right?

One of the (many) things that aren't clear yet is: what if I want to
keep an eye on *everything*?  It seems I can keep an eye on all the
debbugs activity relating to a particular "package" (tho the doc points
me to http://packages.qa.debian.org/ for that, so I'm not sure how that
relates to debbugs), but what about keeping an eye on all packages?

I understand that in the context of Debian, that wouldn't make much
sense because of the sheer volume, but in Emacs that's what we
currently do.

Also how can packages be added/merged/removed/renamed?
E.g. seeing how there isn't any support for development branches, it
would make sense to (ab)use packages for that.  E.g. we'd have
a "lexical" package to keep track of bugs in the
lexical-scoping branch.  But if we ever decide to merge this branch into
the trunk, then all bugs from that package would need to be moved to
the "emacs" package.

Also I'd like to have some way to get a list of all available "packages".


        Stefan

Re: Debbugs testbed

[James Cloos]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

Stefan> One of the (many) things that aren't clear yet is: what if
Stefan> I want to keep an eye on *everything*?

In debian you do that by subscribing to the lists:

debian-bugs-closed
debian-bugs-dist
debian-bugs-forwarded

(all at lists.debian.org).

So I presume debbugs for emacs could be readily configured to CC one
of the emacs lists for everything.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6