bug tracking

bug tracking

[Werner LEMBERG]

Regarding bug tracking via email you might also have a look how the
LaTeX people do it:

  www.latex-project.org


    Werner

Re: bug tracking

[Juanma Barranquero]

On Fri, 18 Jun 2004 17:13:04 +0200 (CEST)
Werner LEMBERG <wl@gnu.org> wrote:

>   www.latex-project.org

Simple and easy, at least from a cursory look, but, is it a custom
development by the LaTex people?

                                                                Juanma

Re: bug tracking

[Werner LEMBERG]

> >   www.latex-project.org
> 
> Simple and easy, at least from a cursory look, but, is it a custom
> development by the LaTex people?

I think so.  You might contact the team for more details, and whether
it is available at all.


    Werner

Re: Bug tracking (was: new *Help* argument highlighting)

[Karl Fogel]

Miles Bader <miles@gnu.org> writes:
> It's critical, IMO -- my experience of using mozilla and savannah's bug
> tracker is that the annoyance of having to go to the web site and muddle
> through the forms significantly decreased the likelihood that I would bother
> (it was fine the first N times, but after a while I started to dread it).

Note that filing bugs by email significantly increases the likelihood
of duplicate issues.  

One of the advantages of going to the web site is that you can first
search to see if the bug already exists in the database.  Whereas if
you fire off an email, there's no query step.  Sure, the editing
environment for an email is better -- Emacs buffer, rather than web
form -- but the web forms *are* also a realtime database front end,
and that makes a difference too.

I'm not sure what interface made you "muddle through forms".  In my
experience, if you're filing a new bug, there's one form to fill out,
and if you're modifying an existing bug, then you just go to a URL and
make the appropriate change.  It's not that hard; I certainly don't
dread it.

Administering existing bugs by email would be nice, of course.  For
example, I'd like to be able to respond to an email sent by the issue
tracker, and have my response cause some new change to the bug.  But
lack of this feature is hardly a showstopper.

Please, let's not aim for perfection, that way lies madness.  Some
issue tracker is better than no issue tracker, and if one sets up the
appropriate bookmarks and URLs, one should never have to muddle
through multiple forms to get things done.

-Karl

Re: Bug tracking (was: new *Help* argument highlighting)

[Miles Bader]

On Sat, Jun 12, 2004 at 04:01:15PM -0500, Karl Fogel wrote:
> > It's critical, IMO -- my experience of using mozilla and savannah's bug
> > tracker is that the annoyance of having to go to the web site and muddle
> > through the forms significantly decreased the likelihood that I would
> > bother (it was fine the first N times, but after a while I started to
> > dread it).
> 
> Note that filing bugs by email significantly increases the likelihood
> of duplicate issues.  
> 
> One of the advantages of going to the web site is that you can first
> search to see if the bug already exists in the database.  Whereas if
> you fire off an email, there's no query step.  Sure, the editing
> environment for an email is better -- Emacs buffer, rather than web
> form -- but the web forms *are* also a realtime database front end,
> and that makes a difference too.

Indeed for the original bug submission, it helps to be able to search the
database, but it's not necessary to use the web to do that (even though you
might want to use an http/html-based interface of some sort for maximum
firewall transparency) -- see debian's bug system for an example of a system
that does most of the work on the client, but also uses a network
database-access protocol of some sort to allow the user to look for old bugs
(it doesn't a perfect interface; something emacs based would likely be much
better).

Note that another important area of bug submission, automatic detection of
environmental parameters, can't be done by a web interface, meaning that the
user is responsible for filling in lots of fussy details, which can make bug
reporting a real chore.

For many `bug management' tasks, the ease of automation and integration into
one's normal workflow make email-friendly systems far superior, especially
if there's an ancillary database-search mechanism that is easily accessible
for automation (i.e. simple enough for an elisp program to use).

> Please, let's not aim for perfection, that way lies madness.

I agree, but I'm not suggesting that, merely trying to establish some
minimal standards.  Purely web-based systems are non-starter.

Thanks,

-Miles
-- 
`Life is a boundless sea of bitterness'

Re: Bug tracking

[Juanma Barranquero]

On Sat, 12 Jun 2004 23:34:52 -0400, Miles Bader <miles@gnu.org> wrote:

> Indeed for the original bug submission, it helps to be able to search the
> database, but it's not necessary to use the web to do that (even though you
> might want to use an http/html-based interface of some sort for maximum
> firewall transparency) -- see debian's bug system for an example of a system
> that does most of the work on the client, but also uses a network
> database-access protocol of some sort to allow the user to look for old bugs
> (it doesn't a perfect interface; something emacs based would likely be much
> better).

I think we agree that, with Emacs, a better system could be done (if not
in absolute terms, definitely better for Emacs-using developers tracking
Emacs-using users :)

Where we differ is, these Emacs-based systems do not exist.  We don't
have a project or a group of people set to create one, we don't have, as
far as I can see, even one developer with the time or the inclination to
create it.  Other systems are less perfect, but the quality of already
existing weights a lot.

> Purely web-based systems are non-starter.

Here, I agree with Karl: we don't have an issue tracker.  How could
having one, even if web-based, be a non-starter?  Nobody's forced to use
it.

                                                           /L/e/k/t/u

Re: Bug tracking

[Miles Bader]

On Sun, Jun 13, 2004 at 01:31:55PM +0200, Juanma Barranquero wrote:
> > Purely web-based systems are non-starter.
> 
> Here, I agree with Karl: we don't have an issue tracker.  How could having
> one, even if web-based, be a non-starter?

Well obviously it's not a comparison against zero; people have always managed
somehow, via files in the source tree, or mailing lists, or whatever.

These ad-hoc systems may not be all that great -- but they may very well be
better than something like what savannah offers.

> Nobody's forced to use it.

Sure, use whatever you want.

-Miles
-- 
"Unless there are slaves to do the ugly, horrible, uninteresting work, culture
and contemplation become almost impossible. Human slavery is wrong, insecure,
and demoralizing.  On mechanical slavery, on the slavery of the machine, the
future of the world depends." -Oscar Wilde, "The Soul of Man Under Socialism"

Re: Bug tracking

[Juanma Barranquero]

On Sun, 13 Jun 2004 09:28:46 -0400, Miles Bader <miles@gnu.org> wrote:

> Well obviously it's not a comparison against zero; people have always managed
> somehow, via files in the source tree, or mailing lists, or whatever.

Sure, you're right.  But my bringing this whole issue is because I feel we
manage, but we don't have information enough.  Perhaps bugs would be
better squashed if people were more conscious about how many have been
reported, their severity, and their status.

> These ad-hoc systems may not be all that great -- but they may very well be
> better than something like what savannah offers.

OK.  But what Savannah offers is not the only option (I hope).

                                                           /L/e/k/t/u

Re: new *Help* argument highlighting

[Juanma Barranquero]

On 12 May 2004 17:15:00 +0900
Miles Bader <miles@lsi.nec.co.jp> wrote:

> Why not use the texinfo convention, @var{name} ?

I was thinking of something similar to substitute-command-keys markers,
i.e., "\<>", "\{}" and "\[]", but I really have no preference and what
you propose seems more sensible. I'll put the issue in my TODO.

Speaking of TODOs and keys... We have etc/TODO, but this is more for
features than bug reports. How do we track bugs pending to be fixed, now
that we're on bug-fixing mode? I posted a bug report for a
keybinding-related issue I don't know how to fix:

"Why does where-is-internal return nil?"
http://mail.gnu.org/archive/html/emacs-devel/2004-04/msg00952.html


                                                                Juanma

Re: new *Help* argument highlighting

[Richard Stallman]

    Speaking of TODOs and keys... We have etc/TODO, but this is more for
    features than bug reports. How do we track bugs pending to be fixed, now
    that we're on bug-fixing mode?

Savannah has some sort of bug-tracking facility, but I have never used
it and I don't know how it works.  Does someone else want to find out?

Bug tracking (was: new *Help* argument highlighting)

[Juanma Barranquero]

On Thu, 13 May 2004 11:45:32 -0400
Richard Stallman <rms@gnu.org> wrote:

> Savannah has some sort of bug-tracking facility, but I have never used
> it and I don't know how it works.  Does someone else want to find out?

I see no bug tracking facility on Savannah, but perhaps I didn't look at
the right places.

Still, the question remains: should we use some kind of issue tracker?

Currently we have an etc/TODO, which is sort of half wish list, half
grab bag of heterogeneous items.  I'm all for using an issue tracker, if
only because it makes easier to know where we are, release-wise, for any
given release.  For example, what's precluding us from doing a
prerelease tarball just today (not that I'm proposing it, of course)?
My guess is that a mix of:

  - Outstanding bugs (each one known to a few developers, the ones more
    interested or knowledgeable on the issue)

  - Pending documentation for new features

  - Undecided status of several patches (dynamic loading, currying,
    overridable faces, etc.)

  - Lack of consensus for the release number (OK, that's only
    half-serious :)

  - Uncertainty about where we stand right now

Of course, issue tracking systems have other advantages than I'm not
going to repeat here, unrelated to whether we're trying to do a release
right now or not.  Almost every serious free or open source project out
there uses one form or another of issue tracking.  We should do it, not
to follow suit, but for the intrinsic gain.

I said a while back that IMHO we should be a more structured project, in
the sense of having a plan for releases, with tentative dates, perhaps
even a release manager, etc.  Someone (Eli, I think, but I'm speaking
from memory) opposed on the grounds that it costs human resources that
we don't have.  But the Emacs project has 87 registered developers;
that's 33% more than Subversion, for example, and they seem to be doing
well on that regard (though, to be fair, they have four or five people
paid to work almost full-time on Subversion).

OTOH, perhaps I'm the only one that feels that way, and I'm just pissing
out my turf...

                                                                Juanma

Re: Bug tracking

[Lars Hansen]

Juanma Barranquero wrote:
> I see no bug tracking facility on Savannah, but perhaps I didn't look at
> the right places.

Look at

https://savannah.gnu.org/bugs/?group=tasklist

You can access it from the savannah start page by selecting
"GNU Task List" in the lower left part of the page, and then look for
"Public Areas: Development Tools".

I don't know anyting about the system, just noticed it was there.
BTW, it seems to be unused.

Re: Bug tracking

[Juanma Barranquero]

On Fri, 11 Jun 2004 13:20:33 +0200
Lars Hansen <larsh@math.ku.dk> wrote:

> https://savannah.gnu.org/bugs/?group=tasklist

https://savannah.gnu.org/bugs/?group=emacs

=> "This project has turned off this tracker [#1];"

so perhaps we could turn it on and take a look.


                                                                Juanma

Re: Bug tracking (was: new *Help* argument highlighting)

[Kim F. Storm]

Juanma Barranquero <jmbarranquero@wke.es> writes:

> I said a while back that IMHO we should be a more structured project, in
> the sense of having a plan for releases, with tentative dates, perhaps
> even a release manager, etc.  Someone (Eli, I think, but I'm speaking
> from memory) opposed on the grounds that it costs human resources that
> we don't have.  But the Emacs project has 87 registered developers;
> that's 33% more than Subversion, for example, and they seem to be doing
> well on that regard (though, to be fair, they have four or five people
> paid to work almost full-time on Subversion).
> 

I really don't understand that we manage to get by without using a bug
tracking system.  We seem to manage, but I'm sure there are many
issues which are never fully addressed and resolved.

I use my personal mail archives and TODO list to keep an eye on issue
that I MIGHT want to look into; actually, I have several mails more
than a year old that I really don't know (without using time I don't
have to find out) if the issue is still unresolved.

A major advantage of bug tracking is also to know WHO (if any) is 
responsible for fixing a given bug.

I have very positive experience with bugzilla from other projects, but
there may be other choices...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug tracking

[Juanma Barranquero]

On 11 Jun 2004 13:39:25 +0200
storm@cua.dk (Kim F. Storm) wrote:

> I really don't understand that we manage to get by without using a bug
> tracking system.  We seem to manage, but I'm sure there are many
> issues which are never fully addressed and resolved.

I have the same feeling: we *seem* to manage.

> I use my personal mail archives and TODO list to keep an eye on issue
> that I MIGHT want to look into; actually, I have several mails more
> than a year old that I really don't know (without using time I don't
> have to find out) if the issue is still unresolved.

Same here.  I had for almost a year and half a personal note to try to
find out what caused the incompatibilities between GnuWin32 image
libraries and MSVC optimized builds.

> A major advantage of bug tracking is also to know WHO (if any) is 
> responsible for fixing a given bug.

Yes.  That also helps when preparing for a release, because people can
take a look at outstanding bug reports and appoint themselves
responsibles for issues in their area of expertise.

Another thing that I find surprising is not having any kind of
regression testing in place.  User interface issues are hard to test
automatically, but there are many things that *could* be tested (the
elisp interpretor, lots of modules, perhaps even the garbage collector).

> I have very positive experience with bugzilla from other projects, but
> there may be other choices...

If we were to use an bug/issue tracker, would it be being on Savannah a
prerequisite? (Not that I have any other system to propose, just to keep
choices open...)

                                                                Juanma

Re: Bug tracking (was: new *Help* argument highlighting)

[Richard Stallman]

    Still, the question remains: should we use some kind of issue tracker?

It would be useful to keep track of the problems that need to be
solved before we can make a release.  However, using some special
"issue tracker" seems like doing it the hard way.  All we need
is a file we can edit.  We can keep it in /etc using CVS and edit
it with Emacs.

The main job is collecting the information to put in the file.

Re: Bug tracking

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
> All we need is a file we can edit.  We can keep it in /etc using CVS
> and edit it with Emacs.

This is the most simple and flexible solution!  Such file could be
in the mail-like format with relevant field names that comprise the
database of bug reports, todo items and news (the latter actually
would be either a bug report or a todo item with `Completed' status).

An example of a record for such database:

Summary: Do this and that
Category: Custom
Priority: High
Status: Open
Submitted: J. Random Hacker
Assigned: J. Random Hacker

Long multi-line description.
Long multi-line description.
Long multi-line description.

^L

"Issue trackers" written in a plain text file have many advantages:
it can be edited directly in Emacs, all changes can be easily tracked
by developers after committing this file to CVS, it allows arbitrary
text-processing operations on a file...

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Bug tracking

[Lars Hansen]

Juri Linkov wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
>>All we need is a file we can edit.  We can keep it in /etc using CVS
>>and edit it with Emacs.
> 
> 
> This is the most simple and flexible solution!  Such file could be
> in the mail-like format with relevant field names that comprise the
> database of bug reports, todo items and news (the latter actually
> would be either a bug report or a todo item with `Completed' status).

IMO database functionality is needed. I should be easy to select items 
having to do with a particular
    module/issuer/maintainer/priority/version of Emacs/OS
and possibly other. Of course that can be done with a text file, but is 
there existing (Emacs lisp) code that can do it? And IMHO it should be 
accessible from the web as well.

Re: Bug tracking

[Juri Linkov]

Lars Hansen <larsh@math.ku.dk> writes:
> IMO database functionality is needed. I should be easy to select items
> having to do with a particular
>     module/issuer/maintainer/priority/version of Emacs/OS
> and possibly other. Of course that can be done with a text file, but
> is there existing (Emacs lisp) code that can do it?

Yes, there is existing Emacs Lisp code (but obviously I am biased).
It is Ee information manager which displays data from text files
in category trees and allows to operate on displayed data:
expand/collapse categories, edit data fields, etc.  It's possible
to create different views for every data file.  Here is an
example http://www.jurta.org/emacs/ee/data/todo.en.html
how a possible issue tracker might look.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Bug tracking

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> Lars Hansen <larsh@math.ku.dk> writes:
> > IMO database functionality is needed. I should be easy to select items
> > having to do with a particular
> >     module/issuer/maintainer/priority/version of Emacs/OS
> > and possibly other. Of course that can be done with a text file, but
> > is there existing (Emacs lisp) code that can do it?
> 
> Yes, there is existing Emacs Lisp code (but obviously I am biased).
> It is Ee information manager which displays data from text files
> in category trees and allows to operate on displayed data:
> expand/collapse categories, edit data fields, etc.  It's possible
> to create different views for every data file.  Here is an
> example http://www.jurta.org/emacs/ee/data/todo.en.html
> how a possible issue tracker might look.

There is also ewoc.el already included in emacs, which might be useful
as the basis of a simple emacs bug tracker interface.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug tracking

[Juri Linkov]

storm@cua.dk (Kim F. Storm) writes:
> Juri Linkov <juri@jurta.org> writes:
>> Yes, there is existing Emacs Lisp code (but obviously I am biased).
>> It is Ee information manager which displays data from text files
>> in category trees and allows to operate on displayed data:
>> expand/collapse categories, edit data fields, etc.  It's possible
>> to create different views for every data file.  Here is an
>> example http://www.jurta.org/emacs/ee/data/todo.en.html
>> how a possible issue tracker might look.
>
> There is also ewoc.el already included in emacs, which might be useful
> as the basis of a simple emacs bug tracker interface.

Thanks for the information.  It seems ewoc.el might be useful as
a data-view connection between a buffer with BUGS text file and
categorized views displayed by Ee.

However, I think we should start with creating a simple mode
to support editing BUGS text files: fontification and completion of
data fields, adding new records from templates, moving existing
records, etc. with all these operations performed on a file buffer.
And later to add other packages to display statistics, summaries,
categorized views and other such additional features in a separate
view buffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Bug tracking

[Juanma Barranquero]

On Mon, 14 Jun 2004 18:09:34 +0300
Juri Linkov <juri@jurta.org> wrote:

> It seems ewoc.el might be useful as
> a data-view connection between a buffer with BUGS text file and
> categorized views displayed by Ee.

Ee is composed of 65 files, 27 of them elisp modules.  It is mature
enough, and generally useful enough, to accept it as a prerequisite for
a issue tracker on elisp?

                                                                Juanma

Re: Bug tracking

[Juri Linkov]

Juanma Barranquero <jmbarranquero@wke.es> writes:
> On Mon, 14 Jun 2004 18:09:34 +0300
> Juri Linkov <juri@jurta.org> wrote:
>> It seems ewoc.el might be useful as
>> a data-view connection between a buffer with BUGS text file and
>> categorized views displayed by Ee.
>
> Ee is composed of 65 files, 27 of them elisp modules.  It is mature
> enough, and generally useful enough, to accept it as a prerequisite for
> a issue tracker on elisp?

It is quite mature: there were no serious problems found for a year.
As for usefulness, I believe it is useful due to its general and simple
interface for presenting data by views with hierarchical categories.

However, I wouldn't say that it should be a prerequisite for managing
bug reports and TODO items in Emacs.  I think they should be editable
as normal text files (though, in a predefined format) without requiring
additional packages.

Issue trackers could be implemented on top of text files as a tool
to display data in different views (with all additional nice features
like statistics, categorizing, etc. that existing issue trackers have)
instead of default flat text.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Bug tracking

[Richard Stallman]

    IMO database functionality is needed. I should be easy to select items 
    having to do with a particular
	module/issuer/maintainer/priority/version of Emacs/OS

It is easy enough to search a file.  If this gets to be large,
something is wrong.  We're not planning to use this to track
individual bugs, and aside from individual bugs, the number of issues
cannot be too large.

What you're proposing would be too costly to set up and maintain.
Our sysadmins would have to do it.  I can't agree to that.

Also, I would be unable to access it.  I usually do not have a net
connection, and often don't even have the possibility of one.
Therefore, I want this info to be kept in a file in the Emacs
repository, so I will be able to look at it and edit it without
a net connection.

If you want to work on Emacs code to do more sophisticated searching
of this file, please go ahead.  That would be a modular improvement
which would not impose any problems elsewhere.

Re: Bug tracking

[Juanma Barranquero]

On Sat, 12 Jun 2004 20:01:23 -0400, Richard Stallman <rms@gnu.org> wrote:

> We're not planning to use this to track
> individual bugs [...]

<sigh>


                                                           /L/e/k/t/u

Re: Bug tracking

[Kai Grossjohann]

Richard Stallman <rms@gnu.org> writes:

> We're not planning to use this to track individual bugs,

Why not?  I thought the discussion was about putting things reported
by M-x report-emacs-bug RET into a database?  (The word database is
to be understood in the broadest possible sense, so that a text file
is also encompassed.)

The mailing list bug-gnu-emacs is nice, but it doesn't provide a list
of open issues, it doesn't provide a way to get a list of bugs that
are being worked on by somebody, and so on.

Kai

Re: Bug tracking

[Juanma Barranquero]

On Sun, 13 Jun 2004 13:55:54 +0200, Kai Grossjohann <kai@emptydomain.de> wrote:

> Why not?  I thought the discussion was about putting things reported
> by M-x report-emacs-bug RET into a database?

When I started the thread, I was talking mainly about exactly *that*;
it's more difficult to manage open bugs that ideas for new developments
or things to finish (etc/TODO could be used for that, even if it isn't
right now).

> The mailing list bug-gnu-emacs is nice, but it doesn't provide a list
> of open issues, it doesn't provide a way to get a list of bugs that
> are being worked on by somebody, and so on.

In other words: it doesn't help in managing open issues.  I fully agree.

                                                           /L/e/k/t/u

Re: Bug tracking

[Juri Linkov]

Juanma Barranquero <lektu@mi.madritel.es> writes:
> When I started the thread, I was talking mainly about exactly *that*;
> it's more difficult to manage open bugs that ideas for new developments
> or things to finish

I agree.  It's a pity so many bug reports are already lost in
bug-gnu-emacs archives without being registered and categorized
by their severity and status.

> (etc/TODO could be used for that, even if it isn't right now).

As I see it, the purpose of etc/TODO is to manage ideas rather
than open bugs.  Open bugs could be placed to a separate file.

So a set of database text files might contain only four files:

etc/BUGS
etc/TODO
etc/DONE
etc/NEWS

That's all that's needed for the simplest issue tracker.

Another question is how to add new bug reports to the BUGS file.
I think this is the task of Emacs developers to register bug
reports from bug-gnu-emacs in the BUGS file, because usually
Emacs users who report bugs on bug-gnu-emacs can't assign right
categories and severity levels to reported bugs.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Bug tracking

[Richard Stallman]

    > We're not planning to use this to track individual bugs,

    Why not?  I thought the discussion was about putting things reported
    by M-x report-emacs-bug RET into a database?

No, this discussion is about tracking issues that need to be
resolved before the release.  Here is the message that raised this
question:

    Still, the question remains: should we use some kind of issue tracker?

    Currently we have an etc/TODO, which is sort of half wish list, half
    grab bag of heterogeneous items.  I'm all for using an issue tracker, if
    only because it makes easier to know where we are, release-wise, for any
    given release.  For example, what's precluding us from doing a
    prerelease tarball just today (not that I'm proposing it, of course)?

The answer to this question is not a list of bug reports; this job is
not bug tracking.

Tracking issues cannot mean bug tracking, because only something
important qualifies as an "issue".  A mere bug report is not (usually)
an issue.  On some occasions a certain bug report might be important
enough to be an issue, but only the Emacs developers can decide when
that is so.  Only the developers can enter issues, and it makes no
sense to have a large number of issues.

A text file is the perfect way to keep track of issues.

Bug tracking might be useful, but it is a completely different
subject.  If we use a bug-tracker, it should be easy to use via email
and cvs.

Re: Bug tracking

[Juanma Barranquero]

On Mon, 14 Jun 2004 14:50:05 -0400, Richard Stallman <rms@gnu.org> wrote:

> No, this discussion is about tracking issues that need to be
> resolved before the release.  Here is the message that raised this
> question:

Put that on English not being my native language.  I was thinking (and
referring, at least on my mind :) to both things.

> A text file is the perfect way to keep track of issues.

On that, I agree.

> Bug tracking might be useful, but it is a completely different
> subject.  If we use a bug-tracker, it should be easy to use via email
> and cvs.

Via CVS?  That meaning?

                                                           /L/e/k/t/u

Re: Bug tracking

[Kim F. Storm]

Juanma Barranquero <lektu@mi.madritel.es> writes:

> On Mon, 14 Jun 2004 14:50:05 -0400, Richard Stallman <rms@gnu.org> wrote:
> 
> > No, this discussion is about tracking issues that need to be
> > resolved before the release.  Here is the message that raised this
> > question:
> 
> Put that on English not being my native language.  I was thinking (and
> referring, at least on my mind :) to both things.
> 
> > A text file is the perfect way to keep track of issues.
> 
> On that, I agree.
> 
> > Bug tracking might be useful, but it is a completely different
> > subject.  If we use a bug-tracker, it should be easy to use via email
> > and cvs.
> 
> Via CVS?  That meaning?


We could start small and simple:

Create an emacs/tracker subdirectory and create text files 1.bug, 2.bug, etc.
with one file for each bug.

Then add a simple header to the file, initially just:

,-------------------------------------
| Subject: Title of this bug
| From: Name and email of original reporter of the bug
| Date: Date created
| Modified: Date last modified
| Status: empty | user name of developer (when assigned) | DELAY | REJECT | DONE
| Priority: RELEASE | FATAL | HIGH | NORMAL | LOW | ...
| Cc: List of email addresses to be notified when tracker is updated
| [empty line]
| Free format text about the bug
`-------------------------------------

Priority = RELEASE means that issue must be resolved before next release.
Priotity = FATAL means this bug makes emacs crash.

Then we can create fairly simple commands like bug-tracker-create
which creates an empty bug tracker, and bug-tracker-commit (bound to
C-c C-c) which checks it into cvs (automatically updating the Modified
date).

We can also make bug-tracker-create-from-message which will take
a mail or news message (in the current buffer) and create a tracker
for it by:

a) select the next unused number in tracker
b) write header + body to that tracker file tracker/N.bug
c) do cvs add + cvs commit on that file

As we progress, we can add more commands that can list, summarize,
search, update those trackers, etc. all with proper interfacing to cvs
(including committing changes at a later time if currently off-line).

The basic idea is that all trackers are recorded as simple text
(mbox-like) files in CVS.

Updates to the trackers will then automatically be mailed to anyone
subscribing to the emacs-diffs mailing list.

Such a system could be written in a couple of hours initially, and expanded
gradually as we find the time and need...  

BTW, progress about the bug can also be recorded in the cvs log, e.g.
changes to Status field.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug tracking

[Miles Bader]

On Tue, Jun 15, 2004 at 01:09:38AM +0200, Kim F. Storm wrote:
> We could start small and simple:
> 
> Create an emacs/tracker subdirectory and create text files 1.bug, 2.bug, etc.
> with one file for each bug.
> 
> Then add a simple header to the file, initially just:

Please look at the link I posted earlier about Andrew Suffield's bug system
which covers many of these issues (it's an email-based system).  I don't know
that we could use his system unchanged, but it might be nice to have at least
a bit of consistency of format or something.

I think the link is:  http://bugs.gnuarch.org

[and then select some link below about explanation]

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Bug tracking

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Tue, Jun 15, 2004 at 01:09:38AM +0200, Kim F. Storm wrote:
> > We could start small and simple:
> > 
> > Create an emacs/tracker subdirectory and create text files 1.bug, 2.bug, etc.
> > with one file for each bug.
> > 
> > Then add a simple header to the file, initially just:
> 
> Please look at the link I posted earlier about Andrew Suffield's bug system
> which covers many of these issues (it's an email-based system).  I don't know
> that we could use his system unchanged, but it might be nice to have at least
> a bit of consistency of format or something.

Sure, but I don't want to go ahead an implement this before
we get some sort of consensus on the topic.


So the question is:

Would the proposed "trackers in cvs" + "emacs frontent" (with no email
interface) be sufficient for you and others who have voiced a strong
rejection of web based trackers?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug tracking

[Richard Stallman]

    > Bug tracking might be useful, but it is a completely different
    > subject.  If we use a bug-tracker, it should be easy to use via email
    > and cvs.

    Via CVS?  That meaning?

I mean that someone like me, who needs to use email and CVS,
should be able to use it with full effectiveness.

Re: Bug tracking

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     IMO database functionality is needed. I should be easy to select items 
>     having to do with a particular
> 	module/issuer/maintainer/priority/version of Emacs/OS
> 
> It is easy enough to search a file.  If this gets to be large,
> something is wrong.  We're not planning to use this to track
> individual bugs, and aside from individual bugs, the number of issues
> cannot be too large.

You lost me there -- how do we track individual bugs then?

I'm sick and tired of having +100 mails and usenet articles that are
constantly marked unread because I might have to look at them -- if
nobody else does that.

To be useful, a bug tracker must record all bugs -- trivial and non-trivial
for the purpose of knowing who (if any) is looking into each of those bugs.

And as a repository of things to look at when we have time.


The interface to the system is less important -- but I don't really
see how you can use a central tracker database if you are off-line 
most of the time.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug tracking

[Miles Bader]

On Mon, Jun 14, 2004 at 12:26:27AM +0200, Kim F. Storm wrote:
> The interface to the system is less important -- but I don't really
> see how you can use a central tracker database if you are off-line 
> most of the time.

It's not important to have an exact to-the-minute copy of the database
(because the rate of change is slow, and conflicts tend not to be critical),
so any solution that allows easy occasional synchronization would be good
enough (and with an email-based system, the synchronization can be one-way --
modification commands typically will get queued with other outgoing email).

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Bug tracking

[Juanma Barranquero]

On Sat, 12 Jun 2004 11:37:05 +0300, Juri Linkov <juri@jurta.org> wrote:

> This is the most simple and flexible solution!

There is flexibility and there is flexibility.  Of course using a
custom-format, text file is the most flexible answer, at the cost of
having no tool other than what we want to develop.  Yes, we have Emacs,
but even Emacs has no "Bug Tracker" major mode, that I know of :)

> "Issue trackers" written in a plain text file have many advantages:
> it can be edited directly in Emacs, all changes can be easily tracked
> by developers after committing this file to CVS, it allows arbitrary
> text-processing operations on a file...

It doesn't have a web interface for other people, no automatic way to
extract statistics, it's *clumsy* beyond belief if you want to also
store past (and fixed or rejected) issues, has to be manually edited by
us so outside people cannot enter issues, needs that someone reads
gnu-emacs-bugs@ reports and formats them as desired, it has limited
posibilities for searching and categorizing...

                                                           /L/e/k/t/u

Re: Bug tracking

[Juri Linkov]

Juanma Barranquero <lektu@mi.madritel.es> writes:
> There is flexibility and there is flexibility.  Of course using a
> custom-format, text file is the most flexible answer, at the cost of
> having no tool other than what we want to develop.  Yes, we have Emacs,
> but even Emacs has no "Bug Tracker" major mode, that I know of :)

Even without special mode a plain text file is the most convenient
way to edit data and to perform arbitrary Emacs operations on them.

> It doesn't have a web interface for other people, no automatic way
> to extract statistics, it's *clumsy* beyond belief if you want to
> also store past (and fixed or rejected) issues, has to be manually
> edited by us so outside people cannot enter issues,

I think there is nothing wrong with the fact that only Emacs
developers will be able to fill bug reports.  So no web interface
is really needed.

> needs that someone reads gnu-emacs-bugs@ reports and formats
> them as desired

That's exactly how it might work: developers read gnu-emacs-bugs,
create new bug entries in the text file and commit them to CVS.
And you can track changes in the text file with all the usual
features of CVS.

> it has limited posibilities for searching and categorizing...

Apart from the Ee categorizing manager, I think that some other
Emacs packages can perform these operations on text files.
AFAIK, at least Gnus should be able to read a text file in the
mail-like format and to treat it as a mail group with bug and TODO
entries as messages.  There are even many possibilities of tighter
integration with its email functionality.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Bug tracking

[Juanma Barranquero]

On Sat, 12 Jun 2004 18:38:29 +0300, Juri Linkov <juri@jurta.org> wrote:

> Even without special mode a plain text file is the most convenient
> way to edit data and to perform arbitrary Emacs operations on them.

No, a plain text file is not necessarily "the most convenient way to
edit data", not by a long shot. Certain kinds of data, yes.  And yes, it
is easi to perform arbitrary Emacs operations on it, but we don't want
to perform arbitrary operations, but a few, very specific, widely used
kinds of operations: the ones usually associated with bug/issue
management.  Your claim is so broad that it seems like you were saying
that Emacs is "the most convenient way" to do anything.

> I think there is nothing wrong with the fact that only Emacs
> developers will be able to fill bug reports.  So no web interface
> is really needed.

Obviously, we *strongly* disagree here.  I see much wrong with only
Emacs developers being able to fill bug reports (for one, that means
someone *has* to do the work which could have made the user).  So the
web interface is, to me, really needed.

> That's exactly how it might work: developers read gnu-emacs-bugs,
> create new bug entries in the text file and commit them to CVS.
> And you can track changes in the text file with all the usual
> features of CVS.

Yes, I understand how could it work, I just happen to think that is a
extraordinarily un-optimized way to do things.  See etc/TODO: would you
dare say that it is really used for the intended purpose?  Many things
in TODO have been there for years, and almost *all* things implemented
or fixed never ever touched TODO.

> Apart from the Ee categorizing manager, I think that some other
> Emacs packages can perform these operations on text files.
> AFAIK, at least Gnus should be able to read a text file in the
> mail-like format and to treat it as a mail group with bug and TODO
> entries as messages.  There are even many possibilities of tighter
> integration with its email functionality.

Aren't you saying that we can shoehorn something into simulating being an
issue tracker, just to *not* use an issue tracker which already does all
that?


                                                           /L/e/k/t/u

Re: Bug tracking

[Miles Bader]

On Sun, Jun 13, 2004 at 12:09:04AM +0200, Juanma Barranquero wrote:
> Yes, I understand how could it work, I just happen to think that is a
> extraordinarily un-optimized way to do things.  See etc/TODO: would you
> dare say that it is really used for the intended purpose?  Many things
> in TODO have been there for years, and almost *all* things implemented
> or fixed never ever touched TODO.

I doubt a fancy `issue tracker' would make a whole lot of difference --
indeed it might make things worse, if it tried to hide what's actually a
simple, relatively small, list of items under an unnecessary search
interface.

I think the best thing for help to get TODO more used would be a bit more
structure / categorization in the file, to make it less daunting for
first-time viewers, and an easy way for regular developers to see changes to
it, without having to explicitly _do_ something, e.g., a special mailing list
just for commit diffs to TODO.

-Miles
-- 
We live, as we dream -- alone....

Re: Bug tracking

[Juanma Barranquero]

On Sat, 12 Jun 2004 19:06:38 -0400, Miles Bader <miles@gnu.org> wrote:

> I doubt a fancy `issue tracker' would make a whole lot of difference --

I was not saying "fancy".  In fact, I have no preference for one or
another, and simple is enough.  But certainly a text file is not what I
was talking about.  I bet it won't be useful.  No, scratch that.  I bet
it won't be used.

> I think the best thing for help to get TODO more used would be a bit more
> structure / categorization in the file, to make it less daunting for
> first-time viewers, and an easy way for regular developers to see changes to
> it, without having to explicitly _do_ something, e.g., a special mailing list
> just for commit diffs to TODO.

So, we should develop a simple issue tracker, instead of using a simple,
already-existing issue tracker...

                                                           /L/e/k/t/u

Re: Bug tracking

[Miles Bader]

On Sun, Jun 13, 2004 at 02:08:05AM +0200, Juanma Barranquero wrote:
> So, we should develop a simple issue tracker, instead of using a simple,
> already-existing issue tracker...

Huh?  Of course not -- if you can find one that actually works for us and
meets the constraints given.  Web-only software need not apply.

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: Bug tracking

[Juanma Barranquero]

On Sat, 12 Jun 2004 20:50:22 -0400, Miles Bader <miles@gnu.org> wrote:

> Huh?  Of course not

What I meant is that we're bound to reproduce, in text files and elisp
modules, an issue tracker.

> if you can find one that actually works for us and
> meets the constraints given.  Web-only software need not apply.

I'll take a look.

                                                           /L/e/k/t/u

Re: Bug tracking

[Juri Linkov]

Juanma Barranquero <lektu@mi.madritel.es> writes:
> What I meant is that we're bound to reproduce, in text files and
> elisp modules, an issue tracker.

Why _bound to reproduce_?  Let's put it another way: we are
_motivated to create_ an Emacs-based issue tracker.  And once
we implement it, even other projects might benefit from that.

As for a web interface, I think it is not an absolute requirement,
and even often undesirable, since a better method for filing bugs
is `report-emacs-bug' which also adds all the necessary information
and doesn't require from Emacs users additional tools.

Though, a some kind of an add-on HTTP<->CVS gateway could be
implemented to sync data between Savannah bug database and text
files in CVS repository, if that becomes absolutely necessary.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Bug tracking

[Juanma Barranquero]

On Sun, 13 Jun 2004 19:00:47 +0300, Juri Linkov <juri@jurta.org> wrote:

> Why _bound to reproduce_?

??

Because (IMHO) we need the functionality of an issue tracker, and we
don't have it implemented.


> Let's put it another way: we are
> _motivated to create_ an Emacs-based issue tracker.

No.  Perhaps you're motivated to create an Emacs-based issue tracker. 
I'm just motivated to *use* an issue tracker, because I think quality
would improve.  I have not a single bit of interest in developing or
helping to develop Yet Another Issue Tracker, and less so because there
are quite a few free ones to pick from.

> As for a web interface, I think it is not an absolute requirement,
> and even often undesirable, since a better method for filing bugs
> is `report-emacs-bug' which also adds all the necessary information
> and doesn't require from Emacs users additional tools.

I think we had already implicitly agreed to disagree on this one...
Every program has a context.  That doesn't mean that the users who take
the trouble to file a bug report are unable to provide that information. 
report-emacs-bug is great, and if it can be integrated with an IT,
wonderful.  But surely is not a precondition.

> Though, a some kind of an add-on HTTP<->CVS gateway could be
> implemented to sync data between Savannah bug database and text
> files in CVS repository, if that becomes absolutely necessary.

"Could be implemented".  Yeah.

                                                           /L/e/k/t/u

Re: Bug tracking

[Miles Bader]

On Mon, Jun 14, 2004 at 12:52:01AM +0200, Juanma Barranquero wrote:
> Every program has a context.  That doesn't mean that the users who take
> the trouble to file a bug report are unable to provide that information. 
> report-emacs-bug is great, and if it can be integrated with an IT,
> wonderful.  But surely is not a precondition.

Most users are _lazy_ -- if reporting a bug entails a lot of extra work,
they'll either give up reporting the bug, or they'll just omit all the info
(if the interface allows it).

-Miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi

Re: Bug tracking

[Juanma Barranquero]

On Sun, 13 Jun 2004 19:56:13 -0400
Miles Bader <miles@gnu.org> wrote:

> Most users are _lazy_ -- if reporting a bug entails a lot of extra work,
> they'll either give up reporting the bug, or they'll just omit all the info
> (if the interface allows it).

Well, two points:

 - Report quality must be not so bad, after all, when many projects use
   IT.  As users usually have to register with an e-mail, interested
   developers can always ask for more info.  That happens right now,
   even with the context information of M-x report-emacs-bug.

 - Certainly, if we are able to use an IT where M-x report-emacs-bug
   creates a report (via de url package or whatever) that'd be great. 
   Nobody's proposing dispensing with this interface.

                                                                Juanma

Re: Bug tracking

[Juanma Barranquero]

On Mon, 14 Jun 2004 09:20:49 +0200
Juanma Barranquero <jmbarranquero@wke.es> wrote:

> via de url package
      ^^
That's a phonetic typo.  Funny.

                                                                Juanma

Re: Bug tracking

[Thien-Thi Nguyen]

Juanma Barranquero <jmbarranquero@wke.es> writes:

      Nobody's proposing dispensing with this interface.

the user interface can be anything but if the data representation is
more complicated than mbox, that's a step away from the shoulders of
giants, etc.

mbox (specifically mime) is tagged and recursive.  it is in use already
by other tracking systems.  general tools to manipulate mbox files are
everywhere.  these add up to a huge hint to the would-be designer of
systems that need to store tagged and recursive data.  not understanding
this hint means the first batch of bugs will be about the bug tracking
system itself, and that batch may be large, and mostly uninteresting.

i think if you separate the user interface question from the data
representation question, you will receive less static.

thi

Re: Bug tracking

[Juanma Barranquero]

On 14 Jun 2004 12:40:43 -0400, Thien-Thi Nguyen <ttn@glug.org> wrote:

> i think if you separate the user interface question from the data
> representation question, you will receive less static.

You lost me there.  My primary interest is user interface, which is what
makes or breaks the success of a bug tracker.  Users must be able to
enter bug reports easily, and developers must be able to see what's done
and what's waiting, who's doing what, etc. also easily  Whether the data
is in cuneiform tablets or tachyonic particles oscillating between
alternate universes is an implementation detail. (Which doesn't mean all
representations are equivalent, obviously).

But in fact, and contrarily to many things heard in this thead, I'm
specifically proposing to develop *nothing* (or at least, almost nothing),
so data representation is an issue for the software already existing out
there, not for me.  I'm hearing about using text files and developing
modes to manage and display that information, and I wonder, who's going
to implement it?  Because I know I'm not (although I will use whatever
we have, if someone invests the effort in developing it).

First, though, we'd have to answer whether we want a bug tracker (as I
proposed), a pending-and-future-issues planner (as I think Richard wants),
both or none.  Personally I find little use in the planner, a text file
(with no custom elisp development) is fine.  But a bug tracker, oh yes,
I strongly think this would be good for the project.

                                                           /L/e/k/t/u

Re: Bug tracking

[Thien-Thi Nguyen]

   From: Juanma Barranquero <lektu@mi.madritel.es>
   Date: Mon, 14 Jun 2004 23:36:56 +0200

   You lost me there.  My primary interest is user interface,
   which is what makes or breaks the success of a bug tracker.
   Users must be able to enter bug reports easily, and developers
   must be able to see what's done and what's waiting, who's doing
   what, etc. also easily.  Whether the data is in cuneiform
   tablets or tachyonic particles oscillating between alternate
   universes is an implementation detail.

a system designer might say the user interface is also an
implementation detail (anything but the block diagram could be
considered so).  my primary interest is in emulating the thought
patterns of (good) system designers.

   But in fact, and contrarily to many things heard in this thead,
   I'm specifically proposing to develop *nothing* (or at least,
   almost nothing), so data representation is an issue for the
   software already existing out there, not for me.  I'm hearing
   about using text files and developing modes to manage and
   display that information, and I wonder, who's going to
   implement it?  Because I know I'm not (although I will use
   whatever we have, if someone invests the effort in developing
   it).

if the design is clean and approachable, the implementation will
tend to happen w/o too much pushing.  i was hoping you would
propose an abstract-ish design in the form of a big block diagram,
taking into consideration the wide-ranging requirements mentioned
thus far, that we could clean up and post somewhere.  the major
effort is in conceiving the big block diagram, IMHO; code will
follow, naturally.

   First, though, we'd have to answer whether we want a bug
   tracker (as I proposed), a pending-and-future-issues planner
   (as I think Richard wants), both or none.  Personally I find
   little use in the planner, a text file (with no custom elisp
   development) is fine.  But a bug tracker, oh yes, I strongly
   think this would be good for the project.

perhaps these are specializations that can be deferred?

thi

Re: Bug tracking

[Juanma Barranquero]

On Tue, 15 Jun 2004 03:36:37 +0200
Thien-Thi Nguyen <ttn@surf.glug.org> wrote:

> i was hoping you would
> propose an abstract-ish design in the form of a big block diagram,
> taking into consideration the wide-ranging requirements mentioned
> thus far, that we could clean up and post somewhere.

No.

There are people here with ideas about how to do it inside an Emacs
framework.  Let's hear them (assuming they want to design such a thing).

> perhaps these are specializations that can be deferred?

You're, IMHO, overgeneralizing.  I'm not interested (in this context) in
reusable, high-level, well-designed, pattern-chocked systems to resolve
general data classification problems.  I just wanted a simple bug
tracker to, you know, track bugs...

                                                                Juanma

Re: Bug tracking

[Richard Stallman]

I will not agree to use of a system that is hard for me to access, so
we simply can't use the systems you have in mind.  Please accept that
decision.  We will use a text file that I can access with CVS.

The number of issues we want to record should not be as much as 50.

    It doesn't have a web interface for other people,

It is not important for anyone to see this file except the Emcs
developers, who will be looking for jobs they can work on to help make
the release happen.

						      no automatic way to
    extract statistics,

The purpose of this database is to keep track of jobs that need to be
done, for the release.  We don't need statistics.  They all will
need to be done.

			it's *clumsy* beyond belief if you want to also
    store past (and fixed or rejected) issues,

We can put the past issues into a DONE file in case anyone wants to
look back at them.

I don't know what you mean by "rejected" issues.  If we don't believe
a job needs to be done for the release, we won't ever put it in this
file.

Perhaps you are envisioning a bug tracking system.  That's not what
this we're trying to do here.

					       has to be manually edited by
    us so outside people cannot enter issues,

Only Emacs maintainers should edit this file.  Outsiders cannot decide
what jobs we need to do before the release, or mark them as done.

					      needs that someone reads
    gnu-emacs-bugs@ reports and formats them as desired,

That will be necessary no matter how we store the file.  Only humans
can decide what should go in the file.  It cannot be done
automatically.

							 it has limited
    posibilities for searching and categorizing...

We should not have so many items in the file that this becomes a
significant issue.

Re: Bug tracking

[Juanma Barranquero]

On Sun, 13 Jun 2004 17:49:32 -0400, Richard Stallman <rms@gnu.org> wrote:

> I will not agree to use of a system that is hard for me to access, so
> we simply can't use the systems you have in mind.

I don't have specific systems in mind.  I've seen one or two that could
be useful (Mantis, for example), because they seem easy.  But I'm not
married to any one answer.

> The number of issues we want to record should not be as much as 50.

You and I are talking about different things.  I brought this up with
regards to issues unfinished, from a release POV.  I'm not sure what you
include in that category: documentation to write, unfinished features,
etc.  But I certainly include in it bug reports, so I cannot put a limit
on "the issues I want to record" of 50 or 100 or any other number.

> The purpose of this database is to keep track of jobs that need to be
> done, for the release.  We don't need statistics.  They all will
> need to be done.

[...]

> We can put the past issues into a DONE file in case anyone wants to
> look back at them.
> 
> I don't know what you mean by "rejected" issues.  If we don't believe
> a job needs to be done for the release, we won't ever put it in this
> file.

I was talking about rejected bug reports, of course.  The ones that are
determined not to be a bug after all.

> Perhaps you are envisioning a bug tracking system.  That's not what
> this we're trying to do here.

Richard, excuse me, but till three days ago, no one was "trying to do"
anything on this matter (in general; of course each one of us has their
particular TODO).  What you now want to do is clear, and what I'm
interested in doing is too, and they aren't the same thing.  I accept
the decision, as you said; i.e., if you create an etc/ISSUES and put in
it things to do, I'll use it.  But this has *nothing* to do with having
or not having a bug/issue tracker.  You're talking of a planner of sorts.

                                                           /L/e/k/t/u

Re: Bug tracking

[Richard Stallman]

    An example of a record for such database:

    Summary: Do this and that
    Category: Custom
    Priority: High
    Status: Open
    Submitted: J. Random Hacker
    Assigned: J. Random Hacker

That general plan is good.

Instead of "Assigned", let's call it "Undertaken".
Here normally people choose to undertake a task,
rather than having it assigned to them.

Also, we should always list the date when the task was
undertaken, so we can tell when something has gone on
for a long time without getting done.

Completed items should be moved to a different file,
so they don't clutter the status of work remaining to be done.

Re: Bug tracking (was: new *Help* argument highlighting)

[Karl Fogel]

Juanma Barranquero <jmbarranquero@wke.es> writes:
> I said a while back that IMHO we should be a more structured project, in
> the sense of having a plan for releases, with tentative dates, perhaps
> even a release manager, etc.  Someone (Eli, I think, but I'm speaking
> from memory) opposed on the grounds that it costs human resources that
> we don't have.  But the Emacs project has 87 registered developers;
> that's 33% more than Subversion, for example, and they seem to be doing
> well on that regard (though, to be fair, they have four or five people
> paid to work almost full-time on Subversion).

A data point:

The Subversion issue tracker database is almost entirely maintained by
unpaid volunteers now.  The salaried developers use it too, of course,
but not in any fundamentally different way than the unpaid developers,
and not proportionally more often.  (There are actually two or three
paid developers, by the way, not four or five).

It's very common for experienced volunteers to help new reporters file
bugs.  For example, a longtime volunteer will often

   1. See a newbie's post on the mailing list,
   2. Solicit more details,
   3. Instruct the newbie in how to file a useful bug report,
   4. Watch to confirm that the newbie did so,
   5. Add some developer-directed comments to the issue if appropriate,
   6. Possibly fix it, if they are a developer themselves.

This process is self-perpetuating.  January's newbie becomes June's
experienced volunteer.

This thread (about whether to have a bug tracker for Emacs) is quite
long, and I can't participate in detail due to time constraints,
unfortunately.  So I'll just say I'm very much in favor of having such
a system -- and yes, to track individual bugs, not just large-scale
future plans.  In the long run, it would save humans much headache,
even though there would be an initial cost to setting it up.

RMS wrote:
> I won't assume it is really good for other projects.
> I don't know whether they have thought about it carefully.
> Techies are often attracted to using the highest tech available
> whether it is better or not.
> 
> It is clear that using a special "issue tracker" would be extra work
> for many people, and it would be hard for me to use.

I understand your skepticism, and in fact harbored similar
reservations when we started Subversion.

However, we did think about it and discuss it quite carefully, both
then and now.  We have no doubt now that it's actually helping us.  It
serves a real need; otherwise we would have dispensed with it long
ago.  Regarding your comment that using an issue tracker would be hard
for you: note that it is not necessary that every developer use the
bug tracker, or use it in the same way, for it to be useful to the
project as a whole.  (I think over time you would find yourself using
it too, though, as using it is often more efficient than avoiding it.)

There is no particular need for this thread to come to a definite
conclusion.  If someone sets up a good tracker and starts using it,
others will follow.  However, it would be nice if the tracker were at
Savannah and advertised from the project pages in some obvious way;
and especially nice if 'M-x report-emacs-bug' and other "official"
sources named it as the canonical database for Emacs bugs.

I wish I had time to set such a thing up, but don't right now.  I hope
someone else does.  FWIW, the Subversion bug tracker is a
[non-portably customized] version of IssueZilla.  It's entirely
web-based.  Lack of a good email interface is one of its serious
flaws, though it hasn't been a fatal flaw for us.

I have no strong opinion about which bug tracker Emacs should use
(except that it be Free of course).  Just the subset of features
common to all bug trackers would already be useful for Emacs...

-Karl

Re: Bug tracking (was: new *Help* argument highlighting)

[Karl Fogel]

Karl Fogel <kfogel@floss.red-bean.com> writes:
> I wish I had time to set such a thing up, but don't right now.  I hope
> someone else does.  FWIW, the Subversion bug tracker is a
> [non-portably customized] version of IssueZilla.  It's entirely
> web-based.  Lack of a good email interface is one of its serious
  ^^^^^^^^^^

Sorry, I misspoke.

While the tracker does not accept input via email, it does send *out*
an email (to a list) whenever a change is made to an issue.  This is
vital functionality, of course.  You can read email to follow what's
going on with bugs, then visit the web forms only when you need to
make a comment or whatever.

(Of course, taking input via email would be even nicer.)

-Karl

Re: Bug tracking (was: new *Help* argument highlighting)

[Miles Bader]

On Sat, Jun 12, 2004 at 03:03:25PM -0500, Karl Fogel wrote:
> While the tracker does not accept input via email, it does send *out*
> an email (to a list) whenever a change is made to an issue.  This is
> vital functionality, of course.  You can read email to follow what's
> going on with bugs, then visit the web forms only when you need to
> make a comment or whatever.
> 
> (Of course, taking input via email would be even nicer.)

It's critical, IMO -- my experience of using mozilla and savannah's bug
tracker is that the annoyance of having to go to the web site and muddle
through the forms significantly decreased the likelihood that I would bother
(it was fine the first N times, but after a while I started to dread it).

-Miles
-- 
"Unless there are slaves to do the ugly, horrible, uninteresting work, culture
and contemplation become almost impossible. Human slavery is wrong, insecure,
and demoralizing.  On mechanical slavery, on the slavery of the machine, the
future of the world depends." -Oscar Wilde, "The Soul of Man Under Socialism"

Re: Bug tracking

[Oliver Scholz]

Miles Bader <miles@gnu.org> writes:

> On Sat, Jun 12, 2004 at 03:03:25PM -0500, Karl Fogel wrote:
[...]
>> (Of course, taking input via email would be even nicer.)
>
> It's critical, IMO -- my experience of using mozilla and savannah's bug
> tracker is that the annoyance of having to go to the web site and muddle
> through the forms significantly decreased the likelihood that I would bother
> (it was fine the first N times, but after a while I started to dread it).

Please bear with my ignorance, if I happen to say something stupid;
but couldn't just Emacs talk to the bug tracking system directly so
that a user has no need to start a browser? I imagine that this would
be less annoying. Of course this would require Emacs being able to do
http. (ISTR that there was talk about adding url to Emacs. Anyways
there is a simple package for http posts out there, written by Alex
Schröder IIRC.)

I envision something like this:

(defun example-report-emacs-bug ()
  (interactive)
  (switch-to-buffer (generate-new-buffer "*Emacs Bug Report*"))
  (let ((widgets nil))
    (widget-insert
     "Bug Report\n\nBla ... blub ...\n\n"
     (make-string fill-column ?-)
     "\n")
    (push
     (widget-create 'editable-field
		    :tag "Your mail address"
		    :format "%t: %v"
		    :size 40
		    :value user-mail-address
		    :value-to-external
		    (lambda (wid val)
		      (format "<email>%s</email>" val)))
     widgets)
    (widget-insert "\n\n")
    (push
     (widget-create 'text
		    :format "%t\n%v"
		    :tag "Please describe the symptoms of the bug"
		    :value "\n\n\n\n"
		    :value-to-external
		    (lambda (wid val)
		      (format "<descr>\n%s\n</descr>" val)))
     widgets)
    (widget-insert "\n\n")
    (widget-create 'push-button
		   :tag "Submit Bug Report"
		   :notify `(lambda (&rest ignore)
			      (example-submit-emacs-bug
			       ',(nreverse widgets))))
    (widget-insert
     "\n\n"
     (make-string fill-column ?-)
     "\n\n
By default Emacs will try to post this bug report via http to 
http://savannah.gnu.org/lirum/larum. If you want to send it via
e-mail instead, please activate the check box below.\n\n")
    (widget-create 'checkbox
		   :tag "Send as e-mail"
		   :format "%v %t")
    (widget-insert
     "\n\nEmacs will also send the information about your environment
\(below you can see which information exactly). If you do not want
this, please activate the check box below.\n\n")
    (widget-create 'checkbox
		   :format "%v %t"
		   :tag "Do not send information about my environment")
    (widget-insert "\n\n"
		   (make-string fill-column ?-)
		   "\n\n... display the information to be sent here ...")
    (use-local-map widget-keymap)
    (widget-setup)))
  
(defun example-submit-emacs-bug (widgets)
  (pop-to-buffer (generate-new-buffer "*example*"))
  (insert (format "<bug-report>\n%s\n</bug-report>"
		  (mapconcat 'widget-value widgets "\n"))))


    Oliver
-- 
Oliver Scholz               26 Prairial an 212 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.       http://www.jungdemokratenhessen.de
Tel. (069) 97 40 99 42      http://www.jdjl.org

Re: Bug tracking

[Richard Stallman]

    Please bear with my ignorance, if I happen to say something stupid;
    but couldn't just Emacs talk to the bug tracking system directly so
    that a user has no need to start a browser?

This does not solve the problem.  The problem is that a web-based
system requires a net connection.  Using Emacs as the client rather
than an ordinary browser might indeed be an improvement in such systems
but it won't help those who have no net connection--such as me.

I have decided that for tracking issues we should use a text file,
not a complex system, and certainly not something web-based.

Re: Bug tracking

[Tak Ota]

Isn't there a system that supports both UUCP like batch email service
as well as web-based service?  I am not a strong advocate of either
system but your comments do not sound forward-looking but anachronism.

Who knows, we may run emacs on a cell phone someday.  I am awfully
impressed by the advancement of today's technology.  I can compile and
run the latest emacs on a MIPS in my target embedded system while I
had to run a fastest workstation for several hours to compile emacs
which was much smaller than today. That was 15 years ago.

-Tak

Mon, 14 Jun 2004 14:50:16 -0400: Richard Stallman <rms@gnu.org> wrote:

>     Please bear with my ignorance, if I happen to say something stupid;
>     but couldn't just Emacs talk to the bug tracking system directly so
>     that a user has no need to start a browser?
> 
> This does not solve the problem.  The problem is that a web-based
> system requires a net connection.  Using Emacs as the client rather
> than an ordinary browser might indeed be an improvement in such systems
> but it won't help those who have no net connection--such as me.
> 
> I have decided that for tracking issues we should use a text file,
> not a complex system, and certainly not something web-based.
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Bug tracking

[Richard Stallman]

    Isn't there a system that supports both UUCP like batch email service
    as well as web-based service?  I am not a strong advocate of either
    system but your comments do not sound forward-looking but anachronism.

It is not my goal to be "forward-looking" for its own sake.  I made
this decision based on practicalities.

When you describe my decision to use low tech as an "anachronism",
that exaggeration means only a sneer at what is unfashionable.
That is unjust, so please don't do it here.

Re: Bug tracking

[Tak Ota]

Wed, 16 Jun 2004 12:57:51 -0400: Richard Stallman <rms@gnu.org> wrote:

> It is not my goal to be "forward-looking" for its own sake.  I made
> this decision based on practicalities.

I understand this but what is practical is quite a subjective issue.
My understanding is that some people raised a question that current
emacs bug tracking mechanism was getting less practical than what was
available out there.

> When you describe my decision to use low tech as an "anachronism",
> that exaggeration means only a sneer at what is unfashionable.
> That is unjust, so please don't do it here.

I am sorry for it sounded as sneering to you.  I have no such
intention.  As network proliferate throughout the society emacs is
becoming net savvy too.  What I wanted to express was let us not go
against it but take advantage of it as long as people without net
connection are not sacrificed.  I do not care about a fashion but the
speed, accuracy, efficiency and convenience of the development.  What
I meant by "anachronism" was that let's not bound rest of the people
to the people who don't have network connection.

I regret I wrote that message.  I should have spent my time for
seeking a solution that I believe is right than writing that
message.  I apologize I wasted your time as well.

-Tak