Why Emacs needs a modern bug tracker

Why Emacs needs a modern bug tracker

[Eric S. Raymond]

This is a slightly edited version of an argument I sent privately
to Stefan Monnier.  In view of Gianluca Della Vedova's observations
on this topic, posting it to the list seems merited.

Stefan wrote, describing Emacs's present workflow:
> In any case the "email access" [requirement] is mostly:
> - users should be able to report bugs via email (and via M-x
>   report-emacs-bug) rather than via the web.
> - all the discussion around a bug should happen via email, basically in
>   the emacs-devel mailing-list.
> 
> I.e. all we need in addition to what we currently have, is a central
> place to record "issues" and link them to specific threads of the
> mailing-list.  This central place should be easily accessible from
> within Emacs, of course, together with a few bindings to Gnus so that
> I can easily add the current message to the list of issues and so I can
> jump from an issue back to the relevant thread.

I think Stefan is expressing a view that is pretty common among the
old-school Emacs devs here.  Alas, I think it's quite far out of
touch with the reality of 2008.

For a project the size of Emacs even Stefan's "all we need" would
be seriously inadequate as described.  What he actually describe
having is so weak a support structure that it probably goes a long way
towards explaining Emacs's troubles and our pathologically long 
development cycle.

Let me explain how I know these things...

I lead another project called GPSD where we don't use an issue tracker
and don't miss it -- we do things the way Emacs now does, all email
bug reports all the time. One thing you can correctly deduce from this
is that I'm not simply attached to issue trackers in some habitual or
irrational way.  When they're not needed, I don't use them.

On the other hand, I know from observation that the Wesnoth project
is seriously slowed down and injured without its issue tracker.
The servers at gna.org occasionally flake out for an hour or two,
and I get to see what happens to productivity.  It's not pretty.

The difference is scale.  GPSD is about 60K lines of code, with a
COCOMO estimate of about 14.2 person-years and about 3 active
developers; normally we only have three or four issues active at once.
Wesnoth is a hair over 100K lines, with a COCOMO estimate of 25.6
years and 10-12 active developers; over the last year we've gone from
about 500 issues tracked to a bit over 300 (currently 196 feature requests,
89 bugs, and the remainder marked Fixed but not yet purged).

Somewhere in the scale range between GPSD and Wesnoth, having an issue
tracker moves from being a dispensable luxury to being an extremely
important tool. Actually, I'm pretty certain it's having a
well-structured issue *database* that's important -- the ability to do
queries like "show me all bugs on Mac OS/X assigned to edb" or "show
me all bugs of severity 'blocker' on the 1.3 branch".

One of the places a real issue database is most concretely useful is when
you're triaging bugs to close on a release.  It is *immensely* helpful
in making clear what needs to be done and at what point you are
finished doing it.

A sequential pile of bug emails, or even indexed email threads, simply
isn't a good enough organization for triaging or release prep at
Wesnoth's scale.  I don't think we'd be able to make four releases a
year if we were stuck to that, let alone a point release every three
weeks.

Now I consider Emacs: 1100K lines, a COCOMO estimate of over 328
years, and no issue database. I think I think I understand much better
now now why the team has only been able to ship one release in five years.
Trying to converge on a releasable state with as poor a view of the
Emacs bug load as we have must be damn near impossible.

Only...I suspect you (the team) don't know how poor your view is,
because you've never had a good view of a bug collection at your scale
to contrast it with.  (To be fair, it's only in the last two or three
years that I have grasped this myself.)

Beside the searchability problems with pile-of-emails organization
is another one; accepting emailed reports makes even *collecting* 
well-structured information about bugs highly problematic.  

The good thing about bug-tracker web forms from a developer point of
view isn't really that they're web, it's that they're *forms*. You can
channel your users into identifying the platform they're running on,
the preceived bug severity, and half a dozen other search keys.

In email, users will embed these things in running text and expect
you to parse them by eyeball.  Which means if you want a database
of bug reports instead of a mere pile of them, you get to re-enter 
each one.  Yuck.  In practice, nobody is ever willing to do this.  

This means that email bug entry needs to be deprecated, redirecting
people to a web form (or, in the special case of Emacs, a simulated
form in emacsbug).  Had you not wondered why Emacs is about the only
major project left that *isn't* trying to push its users onto an issue
tracker?  This is why...

To sum up the back-end argument, the reason I want Emacs to have a
real bug tracker is for the database it will build, so we'll have a
better view of our bugs.  From this (developer) point of view it's
accidental rather than essential that the all the good ones built in
the last decade are Web-facing.

Now let's talk about user experience.

*This* is where browser-centric interfaces become important.  I
know from recent experience on Wesnoth and elsewhere that most users
actually prefer using a well-designed web-based bug tracker to
emailing bug reports.  For them, it *is* about the browser UI.  They
find the structure and the sense of familiarity reassuring.

Gianluca makes exactly this point in his post.  Here is a further
reality check: My wife Cathy is an attorney, not a geek.  She cheerfully 
turns in bug reports on the Wesnoth tracker.  It is not even really
imaginable that she would email to a Wesnoth bug mailing list.  She
tried this once with the KDE guys and had a bad, *bad* experience
of geek snottiness.

Fortunately, most modern issue trackers allow you to feed all the
submissions and followon comments to a designated buglist.  So, if and
when we activate one, you old-schoolers will be able to keep your Gnus
readers.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

A ``decay in the social contract'' is detectable; there is a growing
feeling, particularly among middle-income taxpayers, that they are not
getting back, from society and government, their money's worth for
taxes paid. The tendency is for taxpayers to try to take more control
of their finances...	-- IRS Strategic Plan, (May 1984)

Re: Why Emacs needs a modern bug tracker

[Andreas Röhler]

Am Freitag, 4. Januar 2008 17:44 schrieb Eric S. Raymond:
> This is a slightly edited version of an argument I sent privately
> to Stefan Monnier.  In view of Gianluca Della Vedova's observations
> on this topic, posting it to the list seems merited.
>
> Stefan wrote, describing Emacs's present workflow:
> > In any case the "email access" [requirement] is mostly:
> > - users should be able to report bugs via email (and via M-x
> >   report-emacs-bug) rather than via the web.
> > - all the discussion around a bug should happen via email, basically in
> >   the emacs-devel mailing-list.
> >
> > I.e. all we need in addition to what we currently have, is a central
> > place to record "issues" and link them to specific threads of the
> > mailing-list.  This central place should be easily accessible from
> > within Emacs, of course, together with a few bindings to Gnus so that
> > I can easily add the current message to the list of issues and so I can
> > jump from an issue back to the relevant thread.
>
> I think Stefan is expressing a view that is pretty common among the
> old-school Emacs devs here.  Alas, I think it's quite far out of
> touch with the reality of 2008.
>
> For a project the size of Emacs even Stefan's "all we need" would
> be seriously inadequate as described.  What he actually describe
> having is so weak a support structure that it probably goes a long way
> towards explaining Emacs's troubles and our pathologically long
> development cycle.
>
> Let me explain how I know these things...
>
> I lead another project called GPSD where we don't use an issue tracker
> and don't miss it -- we do things the way Emacs now does, all email
> bug reports all the time. One thing you can correctly deduce from this
> is that I'm not simply attached to issue trackers in some habitual or
> irrational way.  When they're not needed, I don't use them.
>
> On the other hand, I know from observation that the Wesnoth project
> is seriously slowed down and injured without its issue tracker.
> The servers at gna.org occasionally flake out for an hour or two,
> and I get to see what happens to productivity.  It's not pretty.
>
> The difference is scale.  GPSD is about 60K lines of code, with a
> COCOMO estimate of about 14.2 person-years and about 3 active
> developers; normally we only have three or four issues active at once.
> Wesnoth is a hair over 100K lines, with a COCOMO estimate of 25.6
> years and 10-12 active developers; over the last year we've gone from
> about 500 issues tracked to a bit over 300 (currently 196 feature requests,
> 89 bugs, and the remainder marked Fixed but not yet purged).
>
> Somewhere in the scale range between GPSD and Wesnoth, having an issue
> tracker moves from being a dispensable luxury to being an extremely
> important tool. Actually, I'm pretty certain it's having a
> well-structured issue *database* that's important -- the ability to do
> queries like "show me all bugs on Mac OS/X assigned to edb" or "show
> me all bugs of severity 'blocker' on the 1.3 branch".
>
> One of the places a real issue database is most concretely useful is when
> you're triaging bugs to close on a release.  It is *immensely* helpful
> in making clear what needs to be done and at what point you are
> finished doing it.
>
> A sequential pile of bug emails, or even indexed email threads, simply
> isn't a good enough organization for triaging or release prep at
> Wesnoth's scale.  I don't think we'd be able to make four releases a
> year if we were stuck to that, let alone a point release every three
> weeks.
>
> Now I consider Emacs: 1100K lines, a COCOMO estimate of over 328
> years, and no issue database. I think I think I understand much better
> now now why the team has only been able to ship one release in five years.
> Trying to converge on a releasable state with as poor a view of the
> Emacs bug load as we have must be damn near impossible.
>
> Only...I suspect you (the team) don't know how poor your view is,
> because you've never had a good view of a bug collection at your scale
> to contrast it with.  (To be fair, it's only in the last two or three
> years that I have grasped this myself.)
>
> Beside the searchability problems with pile-of-emails organization
> is another one; accepting emailed reports makes even *collecting*
> well-structured information about bugs highly problematic.
>
> The good thing about bug-tracker web forms from a developer point of
> view isn't really that they're web, it's that they're *forms*. You can
> channel your users into identifying the platform they're running on,
> the preceived bug severity, and half a dozen other search keys.
>
> In email, users will embed these things in running text and expect
> you to parse them by eyeball.  Which means if you want a database
> of bug reports instead of a mere pile of them, you get to re-enter
> each one.  Yuck.  In practice, nobody is ever willing to do this.
>
> This means that email bug entry needs to be deprecated, redirecting
> people to a web form (or, in the special case of Emacs, a simulated
> form in emacsbug).  Had you not wondered why Emacs is about the only
> major project left that *isn't* trying to push its users onto an issue
> tracker?  This is why...
>
> To sum up the back-end argument, the reason I want Emacs to have a
> real bug tracker is for the database it will build, so we'll have a
> better view of our bugs.  From this (developer) point of view it's
> accidental rather than essential that the all the good ones built in
> the last decade are Web-facing.
>
> Now let's talk about user experience.
>
> *This* is where browser-centric interfaces become important.  I
> know from recent experience on Wesnoth and elsewhere that most users
> actually prefer using a well-designed web-based bug tracker to
> emailing bug reports.  For them, it *is* about the browser UI.  They
> find the structure and the sense of familiarity reassuring.
>
> Gianluca makes exactly this point in his post.  Here is a further
> reality check: My wife Cathy is an attorney, not a geek.  She cheerfully
> turns in bug reports on the Wesnoth tracker.  It is not even really
> imaginable that she would email to a Wesnoth bug mailing list.  She
> tried this once with the KDE guys and had a bad, *bad* experience
> of geek snottiness.
>
> Fortunately, most modern issue trackers allow you to feed all the
> submissions and followon comments to a designated buglist.  So, if and
> when we activate one, you old-schoolers will be able to keep your Gnus
> readers.


Should the captain leave the bridge and/or pass the
command I'm afraid of bad weather coming too.

Maybe it's the right time to provide something in this
respect, to reconsider Emacs as such, what it shall be,
which direction to take.

With Richard, principles of developing are more or less
immanent by his decisions and experience. 
To keep this waste universe of code running smoothly
 will afterwards need a lot more of
outspoken rules than now.

Concerning the bugtracking: a lot of bugs reported
aren't really one. That can't be changed. What with all
this false bugs in a database?

OTOH some severe bugs seem reported from time to time,
but not fixed so far. Will a database change that?

What about some kind of a blackboard, establishing a
hierarchy of important bugs naming a person in charge
for it?

Thanks all

Andreas Röhler

Re: Why Emacs needs a modern bug tracker

[Eric S. Raymond]

Andreas Röhler <andreas.roehler@online.de>:
> Concerning the bugtracking: a lot of bugs reported
> aren't really one. That can't be changed. What with all
> this false bugs in a database?

The Wesnoth bug/issue tracker has statuses "Wont Fix" and "Invalid".  
Our devs apply these according to their judgment.  Such decisions
have implicit review because everyone on the bug-notification
email list sees the status changes. Sometimes, another dev
will change the tagging, explaining why in a comment.
 
At each release we close bugs still marked Invalid or Wont Fix.
 
> OTOH some severe bugs seem reported from time to time,
> but not fixed so far. Will a database change that?

Not directly, no.  But it will help focus attention on the
most important bugs.

> What about some kind of a blackboard, establishing a
> hierarchy of important bugs naming a person in charge
> for it?

Two of the main purposes of a tracker are (1) to make bug
priority apparent, and (b) to document who, if anyone,
has taken responsibility for each bug.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Why Emacs needs a modern bug tracker

[Gianluca Della Vedova]

Andreas Röhler <andreas.roehler <at> online.de> writes:

> 
> Am Freitag, 4. Januar 2008 17:44 schrieb Eric S. Raymond:
> 
[ stuff deleted ]
> >
> > One of the places a real issue database is most concretely useful is when
> > you're triaging bugs to close on a release.  It is *immensely* helpful
> > in making clear what needs to be done and at what point you are
> > finished doing it.
> >
[ stuff deleted ]

> > Beside the searchability problems with pile-of-emails organization
> > is another one; accepting emailed reports makes even *collecting*
> > well-structured information about bugs highly problematic.
> >
> > The good thing about bug-tracker web forms from a developer point of
> > view isn't really that they're web, it's that they're *forms*. You can
> > channel your users into identifying the platform they're running on,
> > the preceived bug severity, and half a dozen other search keys.
> >
> > In email, users will embed these things in running text and expect
> > you to parse them by eyeball.  Which means if you want a database
> > of bug reports instead of a mere pile of them, you get to re-enter
> > each one.  Yuck.  In practice, nobody is ever willing to do this.
> >
> > This means that email bug entry needs to be deprecated, redirecting
> > people to a web form (or, in the special case of Emacs, a simulated
> > form in emacsbug).  Had you not wondered why Emacs is about the only
> > major project left that *isn't* trying to push its users onto an issue
> > tracker?  This is why...
> >
> > To sum up the back-end argument, the reason I want Emacs to have a
> > real bug tracker is for the database it will build, so we'll have a
> > better view of our bugs.  From this (developer) point of view it's
> > accidental rather than essential that the all the good ones built in
> > the last decade are Web-facing.
> >
> > Now let's talk about user experience.
> >
> > *This* is where browser-centric interfaces become important.  I
> > know from recent experience on Wesnoth and elsewhere that most users
> > actually prefer using a well-designed web-based bug tracker to
> > emailing bug reports.  For them, it *is* about the browser UI.  They
> > find the structure and the sense of familiarity reassuring.
> >
> > Gianluca makes exactly this point in his post.

Almost my point.
I agree that, IMO, the browser UI is better then email for bug submissions.
But I was also referring to the fact emails can get replies that are quite
discomforting, if not nasty or rude: Such a kind of response can quickly lead to
abandon the mailing list. 

A web form is perceived to be more anonymous, and closing a "fake" bug report
without explanation (because it is not really a bug) is not something that can
be taken personally. I don't think the same applies to emails to a mailing list,
where the fact that a bug report is bogus is exposed to everybody.

Part of my post was also devoted to give some of the benefits of the issue
database structure that Eric has clearly described above.

[ stuff deleted ]

> > Fortunately, most modern issue trackers allow you to feed all the
> > submissions and followon comments to a designated buglist.  So, if and
> > when we activate one, you old-schoolers will be able to keep your Gnus
> > readers.
> 

In my blog post (and not in my previous email) I suggested a bug tracker similar
to Debian's. It's main advantage, among other bug tracker I know of, is that it
can be effectively used by email only.

Tipically a bug report is filled on the web (as Eric has suggest it can be
emulated via a Emacs form). For each bug report a unique email address is
created, and the bug report, as well as any subsequent comments is sent also to
such address. The same address can also be used for sending commands for
handling the bug: such commands can be something like "close the bug", or "set
severity to ..".

Since reporting a bug is usually done by a user and not by a developer, I
believe that such a bug tracker could easily fit with the current developers'
modus operandi.

[ stuff deleted ]

> 
> With Richard, principles of developing are more or less
> immanent by his decisions and experience. 
> To keep this waste universe of code running smoothly
>  will afterwards need a lot more of
> outspoken rules than now.
> 

If Emacs is adopting a bug tracker some new rules (i.e. what are the possibile
severity levels) are necessary. 

> Concerning the bugtracking: a lot of bugs reported
> aren't really one. That can't be changed. What with all
> this false bugs in a database?
> 

They can be closed clicking on a button or sending an email with subject
"closed". The effort should not be that much than ignoring the email after
having read it.

> OTOH some severe bugs seem reported from time to time,
> but not fixed so far. Will a database change that?
> 
No.

But some less severe bugs can be fixed by non-core developers, giving more time
for the core developers to work on more important issues.

And the number/quality of users confirming a bug can help in understanding the
actual severity of the bug.


> What about some kind of a blackboard, establishing a
> hierarchy of important bugs naming a person in charge
> for it?
> 

It is one of the purposes on having an issue tracker.

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

If we are to use a bug tracker, it must allow people to do everything
thru email if they wish to, and must make that mode convenient.

Re: Why Emacs needs a modern bug tracker

[Gianluca Della Vedova]

2008/1/5, Richard Stallman <rms@gnu.org>:
> If we are to use a bug tracker, it must allow people to do everything
> thru email if they wish to, and must make that mode convenient.
>

Here follows the description of the Debian bug tracker (called
debbugs). Also there are some Emacs packages for dealing with bug
reports.

"Debian has a bug tracking system which files details of bugs reported
by users and developers. Each bug is given a number, and is kept on
file until it is marked as having been dealt with. The system is
mainly controlled by e-mail, but the bug reports can be viewed using
the WWW.

This version is fully functional, but it does not automatically
configure. See /usr/share/doc/debbugs/README.Debian after
installation.

Note: there might be various issues with this package, caveat emptor. "




-- 
Gianluca Della Vedova
http://www.statistica.unimib.it/~dellavedova

RE: Why Emacs needs a modern bug tracker

[Drew Adams]

> Each bug is given a number, and is kept on
> file until it is marked as having been dealt with.

That *really* sounds like asking for trouble. It deletes the bug history for
a bug that someone deemed had been "dealt with"?

Hard to believe. Bug histories should never be deleted. It should always be
possible to revisit a bug, including to be able to reopen a closed bug.

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

>> Each bug is given a number, and is kept on
>> file until it is marked as having been dealt with.
>
> That *really* sounds like asking for trouble. It deletes the bug history for
> a bug that someone deemed had been "dealt with"?
>
> Hard to believe. Bug histories should never be deleted. It should always be
> possible to revisit a bug, including to be able to reopen a closed bug.

Agreed. All bug systems I know never forgets a report, unless some admin
deletes it from the database.

OTOH, please note that this is independent from the fact that the system
is operated by e-mail.

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Sven Joachim]

On 2008-01-05 20:51 +0100, Drew Adams wrote:

>> Each bug is given a number, and is kept on
>> file until it is marked as having been dealt with.
>
> That *really* sounds like asking for trouble. It deletes the bug history for
> a bug that someone deemed had been "dealt with"?

No.  The bug is merely archived, meaning that it normally is not shown
any more, unless you ask for it.  But its history is never lost.¹

> Hard to believe. Bug histories should never be deleted. It should always be
> possible to revisit a bug, including to be able to reopen a closed bug.

That is all possible with debbugs; if a bug is archived, you first have
to "unarchive" it before you can manipulate it.  That measure ensures
that spam sent to archived bugs is discarded.

Sven


¹ Some of the early Debian bugs _are_ lost, however, because of bugs in
the early versions of `debbugs'. 

RE: Why Emacs needs a modern bug tracker

[Drew Adams]

> >> Each bug is given a number, and is kept on
> >> file until it is marked as having been dealt with.
> >
> > That *really* sounds like asking for trouble. It deletes the
> bug history for
> > a bug that someone deemed had been "dealt with"?
>
> No.  The bug is merely archived, meaning that it normally is not shown
> any more, unless you ask for it.  But its history is never lost.¹
>
> > Hard to believe. Bug histories should never be deleted. It
> should always be
> > possible to revisit a bug, including to be able to reopen a closed bug.
>
> That is all possible with debbugs; if a bug is archived, you first have
> to "unarchive" it before you can manipulate it.  That measure ensures
> that spam sent to archived bugs is discarded.

Thanks for clearing that up. It wasn't clear to me from your initial
expression "kept on file".

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

    Here follows the description of the Debian bug tracker (called
    debbugs). Also there are some Emacs packages for dealing with bug
    reports.

    "Debian has a bug tracking system which files details of bugs reported
    by users and developers. Each bug is given a number, and is kept on
    file until it is marked as having been dealt with. The system is
    mainly controlled by e-mail, but the bug reports can be viewed using
    the WWW.

It sounds like a plausible candidate.  Whether it is really ok in practice
depends on the details of what using it is like.

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

> If we are to use a bug tracker, it must allow people to do everything
> thru email if they wish to, and must make that mode convenient.

I don't know what ESR plans to do, but speaking from my technical
knowledge about the system I use: people would use email by default for
altering bug reports. You could add comentaries, assign owners, close,
and reopen them. The only requisite is that your e-mail message should
carry a prominent, non-ambiguous command and a reference to the bug
report. This is usually a number plus some marker, such as #1341.

Optionally, people could use email for creating bug reports too, through
report-emacs-bug. Those email reports that does not conform to the
format generated by report-emacs-bug would require human intervention to
register them. I volunteer to do that.

For reading them, you either use the web interface or ask the system for
a plain text version of the report(s) you want.

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

    I don't know what ESR plans to do, but speaking from my technical
    knowledge about the system I use: people would use email by default for
    altering bug reports. You could add comentaries, assign owners, close,
    and reopen them. The only requisite is that your e-mail message should
    carry a prominent, non-ambiguous command and a reference to the bug
    report. This is usually a number plus some marker, such as #1341.

That sounds ok, so far.  Can you show me what a couple of these
messages look like?

Also, what is the name of this bug tracker?  We need to think about
which one to use.  We can't just rush to enable _any old_ bug tracker.

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

>     I don't know what ESR plans to do, but speaking from my technical
>     knowledge about the system I use: people would use email by default for
>     altering bug reports. You could add comentaries, assign owners, close,
>     and reopen them. The only requisite is that your e-mail message should
>     carry a prominent, non-ambiguous command and a reference to the bug
>     report. This is usually a number plus some marker, such as #1341.
>
> That sounds ok, so far.  Can you show me what a couple of these
> messages look like?

This would work:

Subject: [some-bug-id] Normal subject text
Message Body:
COMMAND (Optional, if missing the system assumes it's a commentary. A
command could be INVALID, WONTFIX, CLOSE, REOPEN, ASSIGN-TO, etc).
Normal text body.

For instance:

----- Begins e-mail:

From: somebody@somewhere.org
Subject: #2349 Display corrupted on X.
Message Body:
CLOSE

Just committed a fix and blah, blah, blah.

----- Ends e-mail.

That's all.

There are quite a few details to consider, depending on the exact policy
we want to follow. But overall, the use would be no more complex than
the examples above.

> Also, what is the name of this bug tracker?  We need to think about
> which one to use.  We can't just rush to enable _any old_ bug tracker.

Trac: http://trac.edgewall.org/

It nicely integrates a bug tracker, a browser for the VCS and a Wiki (it
does not force you to use everything).

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

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

>> Also, what is the name of this bug tracker?  We need to think about
>> which one to use.  We can't just rush to enable _any old_ bug tracker.
>
> Trac: http://trac.edgewall.org/
>
> It nicely integrates a bug tracker, a browser for the VCS and a Wiki (it
> does not force you to use everything).

Please note that Trac does not support e-mail operation out of the
box. This is something that we need to add (there is a plugin that maybe
does the job at https://subtrac.sara.nl/oss/email2trac )

Another possibility is Roundup ( http://roundup.sourceforge.net/ ) :

  Roundup is a simple-to-use and -install issue-tracking system with
  command-line, web and e-mail interfaces.

In any case, we need to add code for parsing reports created with
report-emacs-bug and add them to the bug tracker, or adapt
report-emacs-bug to the formats that the bug tracker understands. The
second option is not as convenient, as it would affect only future Emacs
releases.

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

    Please note that Trac does not support e-mail operation out of the
    box. This is something that we need to add (there is a plugin that maybe
    does the job at https://subtrac.sara.nl/oss/email2trac )

Would someone like to try running a few bug-trackers
on the bug-gnu-emacs data, and see how usable they are with email?
That way we could make a well-informed choice.

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

"Eric S. Raymond" <esr@snark.thyrsus.com> writes:

[snip]

> Beside the searchability problems with pile-of-emails organization
> is another one; accepting emailed reports makes even *collecting* 
> well-structured information about bugs highly problematic.  

My impression is the contrary: the data provided automatically by
report-emacs-bug seems quite useful and it would be simple to adapt it
for automatic parsing.

> The good thing about bug-tracker web forms from a developer point of
> view isn't really that they're web, it's that they're *forms*. You can
> channel your users into identifying the platform they're running on,
> the preceived bug severity, and half a dozen other search keys.

Precisely, Emacs already knows platform, version, etc.

There is nothing wrong with bug reports by email, as far as they are
automatically integrated on the bug tracker. The problem with email bug
reports is that not all people use emacs as its email client. In most of
my machines, there is no mail support installed at all. Web is more
easily available. IMO a solution is just the actual report-emacs-bug
tuned for automatic extraction of standard data (platform, etc) with a
prominent notice that says something like "if you have not email
support, copy this text and paste it on the form on
http://www.gnu.emacs/bug-report.html".

Emacs not having a bug track system is a bad bad sympton of what is
going on inside the project, but there is no need to throw away all what
is used now. I see no problem supporting a dual system where you deal
with bug reports either by email or by web-forms. An option for
exporting as ASCII text the set of open bugs is no problem, so people
would still have the equivalent of PROBLEMS and TODO.

[snip]

-- 
Oscar

RE: Why Emacs needs a modern bug tracker

[Drew Adams]

> The problem with email bug reports is that not all people use
> emacs as its email client. In most of my machines, there is no
> mail support installed at all.

You don't need to use Emacs as your mail client to make use of
`report-emacs-bug'. When you hit `C-c C-c', Emacs opens your mail client
with a new mail message. You just need to paste the content you prepared.

I use Outlook, for instance, and I file Emacs bugs all the time using
`report-emacs-bug' - no problem. The only thing I do in Outlook is hit `C-v'
to paste my bug report.

For the rest - yes, bug reporting by email can be integrated into a
bug-tracking tool. It's not an either/or choice between a Web form and email
reporting.

Re: Why Emacs needs a modern bug tracker

[Alan Mackenzie]

Hi, Eric!

On Fri, Jan 04, 2008 at 11:44:54AM -0500, Eric S. Raymond wrote:

[ .... ]

> Now I consider Emacs: 1100K lines, a COCOMO estimate of over 328 years,
> and no issue database. I think I understand much better now why the
> team has only been able to ship one release in five years.  Trying to
> converge on a releasable state with as poor a view of the Emacs bug
> load as we have must be damn near impossible.

I think you've got a case, but you're overstating it.  Each (major) Emacs
release goes through exhaustive testing, and this takes many, many
months.  I think RMS can and does keep well abreast of the bug status,
even though I wouldn't be able to with just email.

I don't think we want to do several major releases per year.  Perhaps
once every two years.  Upgrading, for typical users, is nerve-wracking,
and costs time and energy.  They want to do it as little as possible, or
never.  For industrial programmers who are behind schedule (i.e. all of
them), they need a strong reasons before they will upgrade.

> Only...I suspect you (the team) don't know how poor your view is,
> because you've never had a good view of a bug collection at your scale
> to contrast it with.  (To be fair, it's only in the last two or three
> years that I have grasped this myself.)

I've worked many years in industry.  Bug databases done badly are worse,
much worse, than our email archive.

> Beside the searchability problems with pile-of-emails organization
> is another one; accepting emailed reports makes even *collecting* 
> well-structured information about bugs highly problematic.  

Talking of which: however we collect bug reports, we will need moderation
of some sort to exclude spam.  Can we take it that this is a solved
problem?

> The good thing about bug-tracker web forms from a developer point of
> view isn't really that they're web, it's that they're *forms*. You can
> channel your users into identifying the platform they're running on,
> the preceived bug severity, and half a dozen other search keys.

If they're pure web, I doubt they'll be accepted by the hackers here,
who're accustomed to Emacs-quality interfaces.  Whatever we decide on
must be usable from a normal Emacs buffer.

Also, the fields in these forms must be kept under as tight control as a
camp fire in a drought stricken forest.  4 or 5 fields are OK.  8 to 10
are pushing the boundary.  Let a QA department into the works, and before
you know it you've got upwards of 100 largely meaningless fields, so that
said QA "can accurately monitor the trends and problems of the developers
and tune the company's processes accordingly".

> In email, users will embed these things in running text and expect
> you to parse them by eyeball.  Which means if you want a database
> of bug reports instead of a mere pile of them, you get to re-enter 
> each one.  Yuck.  In practice, nobody is ever willing to do this.  

> This means that email bug entry needs to be deprecated, redirecting
> people to a web form (or, in the special case of Emacs, a simulated
> form in emacsbug).  Had you not wondered why Emacs is about the only
> major project left that *isn't* trying to push its users onto an issue
> tracker?  This is why...

I disagree.  An email bug entry system is necessary, and should perhaps
be the preferred method, with a web form as an alternative.  This email
will of course be structured.  M-x report-emacs-bug or C-c C-b (in a CC
Mode buffer) could be enhanced easily enough.

> To sum up the back-end argument, the reason I want Emacs to have a real
> bug tracker is for the database it will build, so we'll have a better
> view of our bugs.  From this (developer) point of view it's accidental
> rather than essential that the all the good ones built in the last
> decade are Web-facing.

> Now let's talk about user experience.

> *This* is where browser-centric interfaces become important.  I
> know from recent experience on Wesnoth and elsewhere that most users
> actually prefer using a well-designed web-based bug tracker to
> emailing bug reports.  For them, it *is* about the browser UI.  They
> find the structure and the sense of familiarity reassuring.

Right.  Eric, unplug your mouse and tell me how well-designed and
reassuringly familiar it is then.  I'm required to drive a bug database
(and other process abortions) by a grotty point and click web interface 8
hours per working day at my day job, and I'm damned if I'm going to come
home and spend my playing time doing the same.  Discarding spam from a
mailman moderation web interface (which I do for help-gnu-emacs and
bug-gnu-emacs) is about as far as I want to go with point and click, and
even that's only tolerable because it's so mindless.

Like Richard said in another thread, we all have different proclivities,
and we _CHOOSE_ our tools to suit us.  By the very nature of our product,
we care deeply about the tools we use.  Perhaps this is the real reason
Emacs is still using email for dealing with bugs, rather than a bug
tracker with a suffocatingly constrained web interface.

> Fortunately, most modern issue trackers allow you to feed all the
> submissions and followon comments to a designated buglist.  So, if and
> when we activate one, you old-schoolers will be able to keep your Gnus
> readers.

Hmmm.  I hope that's not as contumelious as it sounds.  That "allow" had 
better be a first class interface, not just a second rate crock intended
to keep us "outmoded grandads" from moaning.

How about this suggestion: the bug database should be administered by our
super-duper new distributed VCS, having its definitive version at
savannah.  Hackers will then update it by committing (?pushing) their
changes from their own local versions.  With these local versions, they
will have far more usable and flexible facilities than they would over a
lame http connection.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

[snip]

>> Only...I suspect you (the team) don't know how poor your view is,
>> because you've never had a good view of a bug collection at your scale
>> to contrast it with.  (To be fair, it's only in the last two or three
>> years that I have grasped this myself.)
>
> I've worked many years in industry.  Bug databases done badly are worse,
> much worse, than our email archive.

X done badly is worse than not having X... this is a general
justification for rejecting change, not for rejecting bad ideas.

>> Beside the searchability problems with pile-of-emails organization
>> is another one; accepting emailed reports makes even *collecting* 
>> well-structured information about bugs highly problematic.  
>
> Talking of which: however we collect bug reports, we will need moderation
> of some sort to exclude spam.  Can we take it that this is a solved
> problem?

The usual spam-detection schemes works for bug submissions and every
serious bug-tracking system supports them. There is no reason for having
more spam on the bug tracker than on this same mailing list. For the
required human intervention, I volunteer.

[snip]

> Also, the fields in these forms must be kept under as tight control as a
> camp fire in a drought stricken forest.  4 or 5 fields are OK.  8 to 10
> are pushing the boundary.

Most fields are automatically filled by Emacs.

> Let a QA department into the works, and before
> you know it you've got upwards of 100 largely meaningless fields, so that
> said QA "can accurately monitor the trends and problems of the developers
> and tune the company's processes accordingly".

Sure, this is what we can expect from Emacs' corporate culture
<g>. Please be serious. There are no pointy-haired bosses here.

[snip]

>> Now let's talk about user experience.
>
>> *This* is where browser-centric interfaces become important.  I
>> know from recent experience on Wesnoth and elsewhere that most users
>> actually prefer using a well-designed web-based bug tracker to
>> emailing bug reports.  For them, it *is* about the browser UI.  They
>> find the structure and the sense of familiarity reassuring.
>
> Right.  Eric, unplug your mouse and tell me how well-designed and
> reassuringly familiar it is then.  I'm required to drive a bug database
> (and other process abortions) by a grotty point and click web interface 8
> hours per working day at my day job, and I'm damned if I'm going to come
> home and spend my playing time doing the same.
[snip]

I don't use point-and-click for filling web forms, keyboard works fine,
thanks. See available solutions for your web browser. Even for filling
text areas I use an utility that makes possible and convenient to do it
with my favourite text editor.

Really, it not as bad as you paint it, once you (and not your
pointy-haired boss) are the one that controls the tools.

> Like Richard said in another thread, we all have different proclivities,
> and we _CHOOSE_ our tools to suit us.

If we all have different proclivities, why we all use the same tools for
developing Emacs? I guess this is because of consensus. You use CVS,
although others may prefer Arch, and so on. The issue here is: are there
better options? something that enhances our *overall* sense of
gratification?  See, DVCSs are great for working off-line, plus lots of
other major advantages over CVS. However, the proposal had a cold
response by precisely those who valuates working offline as
essential. After reading RMS' replies I'm sure that if he works with a
decent DVCS for a month, he will reject going back to CVS. Seriously.

Please keep an open mind.

> By the very nature of our product, we care deeply about the tools we
> use.  Perhaps this is the real reason Emacs is still using email for
> dealing with bugs, rather than a bug tracker with a suffocatingly
> constrained web interface.

Expressions like "suffocatingly constrained web interface" are too
negative. Maybe you had a bad experience. I only can say that I wish
Emacs' Customize forms were more web-form-alike.

[snip]

> How about this suggestion: the bug database should be administered by our
> super-duper new distributed VCS, having its definitive version at
> savannah.  Hackers will then update it by committing (?pushing) their
> changes from their own local versions.  With these local versions, they
> will have far more usable and flexible facilities than they would over a
> lame http connection.

I was thinking about this possibility and concluded that it is not
possible to build a decent bug-tracking system using only a VCS. The
reason is the importance of the user interface, which must be open to
everybody, not only for the committers, as PROBLEMS and TODO are now,
thus effectively dissuading possible contributions from the
outside. Furthermore, a bug-tracking system needs a database and a VCS
is not good at that.

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
>> I've worked many years in industry.  Bug databases done badly are worse,
>> much worse, than our email archive.
>
> X done badly is worse than not having X... this is a general
> justification for rejecting change, not for rejecting bad ideas.
...
> Sure, this is what we can expect from Emacs' corporate culture
> <g>. Please be serious. There are no pointy-haired bosses here.

Sure, but I think the point is:  we pick what works best for us and our
users, not what satisfies buzzword-completeness.  We surely should
reject change, if it's for the worse!  [Maybe that sounds obvious, but
contemporary corporate culture often does not follow that rule...]

I've used low-quality web bug-trackers (e.g. the one on savannah), and
IMHO, they're no improvement over the status quo -- they have some
advantages, but the disadvantages are also severe.

-Miles

-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

> Sure, but I think the point is:  we pick what works best for us and our
> users, not what satisfies buzzword-completeness.  We surely should
> reject change, if it's for the worse!  [Maybe that sounds obvious, but
> contemporary corporate culture often does not follow that rule...]
>
> I've used low-quality web bug-trackers (e.g. the one on savannah), and
> IMHO, they're no improvement over the status quo -- they have some
> advantages, but the disadvantages are also severe.

You are right on some aspect: so far there was too much insistence on
how old-fashioned Emacs' development is and how cool modern practices
are. Of course, this approach is wrong. We, the advocates of change,
should provide more evidence supporting our proposals. It was a good
thing seeing how RMS changed his mind as soon as someone demonstrated
how a DVCS would enhance his actual way of working.

For the bug tracker, I'm afraid it will not so easy. Most likely,
current Emacs developers should trade some diary personal incovenience
for some long-term project development efficiency. On the other hand, it
is difficult to appreciate the convenience of having an audit of a bug
or feature until you are using the system for some months.

Finally, please remember that nobody is suggesting "one true way" to
project management. IMHO ESR's proposal is too radical. I'm convinced
that there is no need to completely depart from current practices and we
can settle a point where Emacs development is improved and becomes more
attractive for prospecting developers without turning it boring for the
current ones.

It's just a matter of constructive dialogue.

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Eli Zaretskii]

> From: =?iso-8859-1?Q?=D3scar_Fuentes?= <ofv@wanadoo.es>
> Date: Sat, 05 Jan 2008 03:54:23 +0100
> 
> You are right on some aspect: so far there was too much insistence on
> how old-fashioned Emacs' development is and how cool modern practices
> are. Of course, this approach is wrong. We, the advocates of change,
> should provide more evidence supporting our proposals.

Not just evidence: you should volunteer to do actual work.  One of the
main weaknesses of Emacs development is (IMO) scarce resources (scarce
for such a humongously large package).  Many good ideas posted to this
list through the years were never implemented for that very reason.

A bug tracker is a good case in point: Richard stated quite some time
ago the basic requirements for his acceptance of such a tool, but no
one stepped forward to do anything practical about that.

You might argue that this is a chicken-and-egg problem: if the tools
we use were more efficient, more developers would have come on board.
That might be so, but I challenge you (and other proponents of change)
to break the vicious circle by making things happen.

> For the bug tracker, I'm afraid it will not so easy. Most likely,
> current Emacs developers should trade some diary personal incovenience
> for some long-term project development efficiency. On the other hand, it
> is difficult to appreciate the convenience of having an audit of a bug
> or feature until you are using the system for some months.

Starting such a system, but not making it mandatory, would be a good
step towards the goal of having a good tracker in the future.  In
general, a controversial feature should start as an option, before it
becomes the default.

Re: Why Emacs needs a modern bug tracker

[Juanma Barranquero]

On Jan 5, 2008 4:38 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> That might be so, but I challenge you (and other proponents of change)
> to break the vicious circle by making things happen.

FWIW, Eric clearly stated in the first few messages of this thread
that he was willing to work to "make things happen".

             Juanma

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Not just evidence: you should volunteer to do actual work.
[snip]

ESR volunteered for implementing the DVCS and the bug-tracker. I
volunteered for spam-filtering and monitoring the bug-tracker. I can do
other misc things, such as pre-testing the system and later assist other
users on its use.

> A bug tracker is a good case in point: Richard stated quite some time
> ago the basic requirements for his acceptance of such a tool, but no
> one stepped forward to do anything practical about that.

I'll be grateful if you direct me to the message where this requirements
were stated. I failed to find it on the archives.

>> For the bug tracker, I'm afraid it will not so easy. Most likely,
>> current Emacs developers should trade some diary personal incovenience
>> for some long-term project development efficiency. On the other hand, it
>> is difficult to appreciate the convenience of having an audit of a bug
>> or feature until you are using the system for some months.
>
> Starting such a system, but not making it mandatory, would be a good
> step towards the goal of having a good tracker in the future.  In
> general, a controversial feature should start as an option, before it
> becomes the default.

A bug tracker that is not updated by its users is worse than not having
a bug tracker. :-) Really, what is important is that bugs are entered on
the system. Users will do. You too, if you use report-emacs-bug. The
rest comes with little effort. Those who do not want web operation still
see the copy published on emacs-*-bugs (just as it happens today) and
can request from the system the equivalent of PROBLEMS and TODO with
simply a wget. You will not have files attached to the reports, such as
screenshots, but you have not them today either. Of course, you will be
allowed to request a single report intead of the full set of open
issues. When you fix something, just say in your commit message "Fixes
#1354" and the system will automatically close that bug (plus doing
other nice things). If you want to add a comment to a bug report, just
sending email to some emacs development mailing list mentioning its
number on the message subject would be enough. A sophisticated system
can inspect the body as well, so you can see in the bug report all
messages that ever mentioned it. No more black holes.

A bug tracker is a dynamic system in the sense that it can take
sophisticated actions in response to its input, and we can exploit this
on a variety of ways. A problem I perceive from the outside is that, for
a casual Emacs contributor, it is too hard to monitor mailing lists
looking for bug reports concerning the module(s) you maintain. The bug
tracker can associate an "owner" for every report. This owner is
determined either by the reporter's choice of affected module (say
cc-mode), or by some overseer that performs a superficial analysis of
the report (such person does not need to know a lot about Emacs
internals, an ignorant like me could do a decent job). The bug tracker
notifies the owner about the new bug and he can query the system for the
bugs assigned to him.

The advantages of a living database over a static text file are too
large to enumerate.

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Lennart Borgman (gmail)]

Óscar Fuentes wrote:
> I'll be grateful if you direct me to the message where this requirements
> were stated. I failed to find it on the archives.


Here is one piece, sent to this thread today:

Richard Stallman wrote:
 > If we are to use a bug tracker, it must allow people to do everything
 > thru email if they wish to, and must make that mode convenient.

Re: Why Emacs needs a modern bug tracker

[Eli Zaretskii]

> From: =?iso-8859-1?Q?=D3scar_Fuentes?= <ofv@wanadoo.es>
> Date: Sat, 05 Jan 2008 20:05:42 +0100
> 
> > Not just evidence: you should volunteer to do actual work.
> [snip]
> 
> ESR volunteered for implementing the DVCS and the bug-tracker. I
> volunteered for spam-filtering and monitoring the bug-tracker. I can do
> other misc things, such as pre-testing the system and later assist other
> users on its use.

Yes, I know.  But -- and please forgive me for being so blunt -- I
have enough grey hair to remember a few instances in the past where
people with good intentions said things like that.  Sadly, intentions
are all we are left with to this day.

I want to see some action, in addition to good intentions and more
talking.

> > A bug tracker is a good case in point: Richard stated quite some time
> > ago the basic requirements for his acceptance of such a tool, but no
> > one stepped forward to do anything practical about that.
> 
> I'll be grateful if you direct me to the message where this requirements
> were stated. I failed to find it on the archives.

What did you look for?  "bug tracker" worked for me.

Try the thread which started with this message:

  http://lists.gnu.org/archive/html/emacs-devel/2006-10/msg00484.html

> A bug tracker that is not updated by its users is worse than not having
> a bug tracker. :-)

    X done badly is worse than not having X... this is a general
    justification for rejecting change, not for rejecting bad ideas.

These are not my words, they're yours, posted just a few hours ago.

> The advantages of a living database over a static text file are too
> large to enumerate.

But the advantage of the flat text file is that it exists.

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Not just evidence: you should volunteer to do actual work.
>> [snip]
>> 
>> ESR volunteered for implementing the DVCS and the bug-tracker. I
>> volunteered for spam-filtering and monitoring the bug-tracker. I can do
>> other misc things, such as pre-testing the system and later assist other
>> users on its use.
>
> Yes, I know.  But -- and please forgive me for being so blunt -- I
> have enough grey hair to remember a few instances in the past where
> people with good intentions said things like that.  Sadly, intentions
> are all we are left with to this day.
>
> I want to see some action, in addition to good intentions and more
> talking.

You have experience dealing with ESR. Don't you trust him?

I think that the reimplementation of VC that ESR just accomplished
involves an amount of work of the same order than implementing the
systems he proposed. I never was involved with ESR, but his offer seems
pretty credible to me.

>> > A bug tracker is a good case in point: Richard stated quite some time
>> > ago the basic requirements for his acceptance of such a tool, but no
>> > one stepped forward to do anything practical about that.
>> 
>> I'll be grateful if you direct me to the message where this requirements
>> were stated. I failed to find it on the archives.
>
> What did you look for?  "bug tracker" worked for me.

I'm using the search facility at
http://lists.gnu.org/archive/html/emacs-devel/ and when I enter "bug
tracker" or "bug database" (quotes included) the result is

References: [ (Too many documents hit. Ignored) ] 

No document matching your query.

> Try the thread which started with this message:
>
>   http://lists.gnu.org/archive/html/emacs-devel/2006-10/msg00484.html

Thanks! Reading it.

>> A bug tracker that is not updated by its users is worse than not having
>> a bug tracker. :-)
>
>     X done badly is worse than not having X... this is a general
>     justification for rejecting change, not for rejecting bad ideas.
>
> These are not my words, they're yours, posted just a few hours ago.

That is not the same case. There are certain tools that must do its job
well enough. If you usually search the mailing list for data about a
bug, the bug system is offering little gain. Basically, you are doing
more work than before: now you must look into the bug system and the
mailing list. Absurd.

But as I mentioned on the message you quoted, I think this will not
happen, as the bug system would monitor the mailing list and swallow
data from there.

>> The advantages of a living database over a static text file are too
>> large to enumerate.
>
> But the advantage of the flat text file is that it exists.

Seriously, I don't understand your attitude. Is like somebody were
asking you to take some risk.

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Reiner Steib]

On Sat, Jan 05 2008, Óscar Fuentes wrote:

> I'm using the search facility at
> http://lists.gnu.org/archive/html/emacs-devel/ and when I enter "bug
> tracker" or "bug database" (quotes included) the result is
>
> References: [ (Too many documents hit. Ignored) ] 
>
> No document matching your query.

I'd suggest to use <http://search.gmane.org/> and add emacs.devel in
the group field:

<http://search.gmane.org/?query=bug%20tracker&group=emacs.devel&author=Stallman>

BTW, when searching for bug, you can use emacs.pretest.bugs or
emacs.bugs in the group field.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Why Emacs needs a modern bug tracker

[David Kastrup]

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

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> > Not just evidence: you should volunteer to do actual work.
>>> [snip]
>>> 
>>> ESR volunteered for implementing the DVCS and the bug-tracker. I
>>> volunteered for spam-filtering and monitoring the bug-tracker. I can do
>>> other misc things, such as pre-testing the system and later assist other
>>> users on its use.
>>
>> Yes, I know.  But -- and please forgive me for being so blunt -- I
>> have enough grey hair to remember a few instances in the past where
>> people with good intentions said things like that.  Sadly, intentions
>> are all we are left with to this day.
>>
>> I want to see some action, in addition to good intentions and more
>> talking.
>
> You have experience dealing with ESR. Don't you trust him?

Well, the most recent experience is the VC reorganisation which was
checked into the trunk in a non-finished state and then left in the
lurch for others to sort out themselves for about half a year.

However this may have come about, it is not a workflow that really
inspires confidence in the procedures and communication needed for
people in charge of important subsystems, in particular if one calls for
faster releases.

I can't blame Eli for being sceptical about the wisdom of introducing
more single points of failure hinging on a one-person effort.

So the question remains: where do we all (not just ESR) want to go, and
will others be able to pick up the slack in case that ESR has to drop
the ball for some reason?

> I think that the reimplementation of VC that ESR just accomplished
> involves an amount of work of the same order than implementing the
> systems he proposed. I never was involved with ESR, but his offer
> seems pretty credible to me.

The VC reorganization still appears to be an ongoing effort right now.

>>> The advantages of a living database over a static text file are too
>>> large to enumerate.
>>
>> But the advantage of the flat text file is that it exists.
>
> Seriously, I don't understand your attitude. Is like somebody were
> asking you to take some risk.

Introducing a new dependency for working is a risk.  If people stop
reporting bugs in the current way, one has to change the workflow of the
potential bugfixers.  Not all of them will do this.  If stuff gets
stuck, one can't easily return to the old way of doing things since a
different report-emacs-bug would already be out in the wild.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

[snip]

> Introducing a new dependency for working is a risk.  If people stop
> reporting bugs in the current way, one has to change the workflow of
> the potential bugfixers. Not all of them will do this.  If stuff gets
> stuck, one can't easily return to the old way of doing things since a
> different report-emacs-bug would already be out in the wild.

At least with the method I mentioned elsewhere, the only change to
report-emacs-bug is the disposition of the autogenerated text. It would
be sent to emacs-bugs as it is today. There, the bug-tracker
automatically would create the report and associate to it all ongoing
mail discussion and VCS activity.

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Eli Zaretskii]

> From: =?iso-8859-1?Q?=D3scar_Fuentes?= <ofv@wanadoo.es>
> Date: Sat, 05 Jan 2008 21:38:55 +0100
> 
> > Yes, I know.  But -- and please forgive me for being so blunt -- I
> > have enough grey hair to remember a few instances in the past where
> > people with good intentions said things like that.  Sadly, intentions
> > are all we are left with to this day.
> >
> > I want to see some action, in addition to good intentions and more
> > talking.
> 
> You have experience dealing with ESR. Don't you trust him?

This isn't about trust.  I _really_ want Emacs to move forward faster,
and I'm tired of long arguments that change nothing except the size of
email archives, that's all.

> >> The advantages of a living database over a static text file are too
> >> large to enumerate.
> >
> > But the advantage of the flat text file is that it exists.
> 
> Seriously, I don't understand your attitude.

See above: as long as all we do is talk, a flat text file is better
than just talk.

Re: Why Emacs needs a modern bug tracker

[Bastien]

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

> A bug tracker is a dynamic system in the sense that it can take
> sophisticated actions in response to its input, and we can exploit this
> on a variety of ways.  A problem I perceive from the outside is that, for
> a casual Emacs contributor, it is too hard to monitor mailing lists
> looking for bug reports concerning the module(s) you maintain. The bug
> tracker can associate an "owner" for every report. This owner is
> determined either by the reporter's choice of affected module (say
> cc-mode), or by some overseer that performs a superficial analysis of
> the report (such person does not need to know a lot about Emacs
> internals, an ignorant like me could do a decent job). The bug tracker
> notifies the owner about the new bug and he can query the system for the
> bugs assigned to him.
>
> The advantages of a living database over a static text file are too
> large to enumerate.

org-mode does pretty well in handling text files *dynamically* from
within Emacs.

To be more concrete, here is an example of a possible TODO.org file:

========================================================================
* Important bugs

* Small bugs

** TODO Fix issue about fontication in picasso-mode
   DEADLINE: <2008-01-28 lun>
   :PROPERTIES:
   :MAINTAINER: pablo@cubism.net
   :EMAIL: [[http://news.gmane.org/find-root.php?message_id=%3C20080104164454.0A4BD830697%40snark.thyrsus.com%3E]]
   :FOR_RELEASE: 23.1
   :END:

This part of the bug item may contain more detailed explanations about
the bug.  But this is not mandatory.

** INPROGRESS Fix documentation bug for zen-mode
   :PROPERTIES:
   :MAINTAINER: confucius@stayaway.org
   :EMAIL: [[http://news.gmane.org/find-root.php?message_id=%3C22342347.0A4BD830697%40test.server.com%3E]]
   :FOR_RELEASE: 23.0
   :END:

* Feature requests
========================================================================

Depending on your needs, you then can look at this file from many
different perspectives.  You might want to look for entries that are
handled by someone specific, or entries that are crucial for the next
release, or entries that are currently in the INPROGRESS status...

Again, the main advantage here is that this way of handling bug and
development issues requires a small amount of work on the top of the
actual files in emacs/etc.  

I guess Using Org would help making Emacs tasks sneak into Emacs
developers to-do lists...

-- 
Bastien

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

Bastien <bzg@altern.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> The advantages of a living database over a static text file are too
>> large to enumerate.
>
> org-mode does pretty well in handling text files *dynamically* from
> within Emacs.
[snip]

Sorry, but org-mode is no match for a proper bug system. Do you expect
end users filling well-structured bug reports on a plain text file? How
do you perform complex queries? What to do with closed bugs? What
happens when the file grows to several dozen megabytes? How do you store
attached files?  What to do with test cases that includes text in
arbitrary encodings? How do you integrate e-mail traffic on emacs-devel
and emacs-*-bugs into the text file without hammering the VCS with
thousands of commits per month just for storing discussions and other
activity about bugs?  Will org-mode notify a maintainer when a bug is
assigned to him? Will it interact with the VCS to associate bugs and
commits?

And so on.

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Bastien]

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

> Bastien <bzg@altern.org> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> The advantages of a living database over a static text file are too
>>> large to enumerate.
>>
>> org-mode does pretty well in handling text files *dynamically* from
>> within Emacs.
> [snip]
>
> Sorry, but org-mode is no match for a proper bug system. 

Just quoting myself:

  Of course, having better TODO and PROBLEMS files does not help when it
  comes to let users send bug reports.  But making things easier for the
  developers and making things easiers for the users are two distincts
  issues, which may be addressed with distinct tools.

I think that using org-mode can help Emacs developers to make a more
effective use of the Emacs TODO file.  This sounds like a reasonable
(i.e. incremental, Emacs-based) proposal in the context of this long
discussion about productivity enhancement.

> Do you expect end users filling well-structured bug reports on a plain
> text file?

No.  I expect users will continue sending bug reports thru emails, then
people filtering these reports and feed an Org database.  If the reports
are well-formatted enought, this filtering could also be automated, just
as it will be with a normal bug tracker.

> How do you perform complex queries?

Org lets you perform any search/query you want.

> What to do with closed bugs? 

You put the item in a close state.  Usually by associating the entry
with the DONE to-do keyword.

> What happens when the file grows to several dozen megabytes? 

The TODO file distributed with Emacs could contains only the main
issues, while the full TODO could live elsewhere.

> How do you store attached files?  What to do with test cases that
> includes text in arbitrary encodings? 

As I said, having a better TODO file would not replace the mailing list
as a primary tool. It would just help with filtering the issues, knowing
about their status, who's in charge, etc.  

> How do you integrate e-mail traffic on emacs-devel and emacs-*-bugs
> into the text file without hammering the VCS with thousands of commits
> per month just for storing discussions and other activity about bugs?

Have a separate TODO file.

> Will org-mode notify a maintainer when a bug is assigned to him?

A cron job could go through the TODO.org file, gather issues that
someone is in charge of, and send the headlines to him.

But my point is not that org-mode can be used as a bug tracker.  It is
that you can use org-mode to improve the way the TODO file is currently
used.  Actually, using org to improve the TODO file as an internal tool
and using whatever bug tracker you want for users are not exclusive.  

But I won't insist too much on this, there is enough passion in this
thread :)

-- 
Bastien

Re: Why Emacs needs a modern bug tracker

[Bastien]

Bastien <bzg@altern.org> writes:

> I think that using org-mode can help Emacs developers to make a more
> effective use of the Emacs TODO file.  This sounds like a reasonable
> (i.e. incremental, Emacs-based) proposal in the context of this long
> discussion about productivity enhancement.

I've edited the current CVS etc/TODO file and made it org friendly:

  http://www.cognition.ens.fr/~guerry/u/TODO.org

Open this file in Emacs with a recent version of Org (say >5.00), and
activate the column view with C-c C-x C-c.  It will display something
like a table (via overlays) showing metadata attached to each item.

You can see these columns: status, importance, owner, version, system,
milestone, and file.  Org-mode lets you select items depending on tags,
keywords, properties, etc., so that it's easy to quickly review query
through this, as you would do through a web-based bug tracker.

I just spent 10 minutes editing this TODO file, just to give a flavor of
what can be done with org-mode.  Of course, the information we want to
handle depends on the conventions we use as a collective workflow.

Even if we don't draw any automatic bridge between the mailing list and
such an Org file, I think it's worth enhancing the current TODO file...

-- 
Bastien

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

    I've edited the current CVS etc/TODO file and made it org friendly:

      http://www.cognition.ens.fr/~guerry/u/TODO.org

It is interesting.  I don't really know how to use Org mode, but
I could learn.

If someone adds an ordinary entry of the form used in etc/TODO,
what will Org mode do with it?  Will it get confused?

    You can see these columns: status, importance, owner, version, system,
    milestone, and file.

I don't see the ones past "version".  I guess they are truncated.
What is the command to view them?

Re: Why Emacs needs a modern bug tracker

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>     I've edited the current CVS etc/TODO file and made it org friendly:
>
>       http://www.cognition.ens.fr/~guerry/u/TODO.org
>
> It is interesting.  I don't really know how to use Org mode, but
> I could learn.
>
> If someone adds an ordinary entry of the form used in etc/TODO,
> what will Org mode do with it?  Will it get confused?

Not at all.  

Even though it would be better to have shorter headings, putting the
full description of the issues in the subtree itself.

Doing M-x org-mode on TODO will hide all the the subtrees.  

Each item can then be unfolded with the TAB key, which cycle the
visibility of the entry at point through these states: fold, show
children, show all.  Nothing that you wouldn't be able to achieve 
with outline and a combination of hide-* show-*, but Org makes it 
easy.

>     You can see these columns: status, importance, owner, version, system,
>     milestone, and file.
>
> I don't see the ones past "version".  I guess they are truncated.
> What is the command to view them?

M-x org-columns

The line starting with #+COLUMNS: is really a formatting line defining
what properties should be displayed in the columns.  Obviously the total
width of the columns is too large for you.  When the column view is
active, you can move columns to the left or to the right with M-<left>
or M-<right>.

But first things first: the column view is a pretty advanced feature of
Org.  Before that, there are to-do keywords and tags.  

The manual is very accurate, but let me know if you need more pointers. 

-- 
Bastien

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

    A bug tracker that is not updated by its users is worse than not having
    a bug tracker. :-) Really, what is important is that bugs are entered on
    the system. Users will do. You too, if you use report-emacs-bug. The
    rest comes with little effort. Those who do not want web operation still
    see the copy published on emacs-*-bugs (just as it happens today) and
    can request from the system the equivalent of PROBLEMS and TODO with
    simply a wget.

That is already starting to be a bit less convenient than now.
Right now I get the latest copy of everything with CVS.

     You will not have files attached to the reports, such as
    screenshots, but you have not them today either.

Why wouldn't we get them in the email?

     When you fix something, just say in your commit message "Fixes
    #1354" and the system will automatically close that bug (plus doing
    other nice things).

That sounds convenient, as far as it goes.  Does this particular bug
tracker let people control every ticket by sending email to a special
address?

Re: Why Emacs needs a modern bug tracker

[Thien-Thi Nguyen]

() Óscar Fuentes <ofv@wanadoo.es>
() Sat, 05 Jan 2008 20:05:42 +0100

   The advantages of a living database over a static text file
   are too large to enumerate.

a database has structure amenable to non-human manipulation.
that is its advantage.  that's not too large to enumerate, is it?
true, structure may be too large for an inexperienced programmer
to design, but that's the bonus of design: form + experience.

of course living is more fun than dead, so i ignore that.

so let's move from theory to practice.  what is the
design of this database?  here is one example:

EDB, the Emacs Data Base, tracks its own bugs using itself
(and emacs, it almost goes w/o saying).  please see:

  http://www.gnuvola.org/edb/BUGS  <-- a living static
                                       data base text file!

  http://www.gnuvola.org/edb/edb-1.28p2.tar.gz

the latter is a tarball that contains BUGS and BUGS.edb.
BUGS.edb tells EDB the structure of BUGS.

since emacs can be a server, it's just a SMOP to add
email/web handling to the above to get an all-emacs-lisp
(please) bugzilla-ish prototype up by eow.  any takers?

thi

Re: Why Emacs needs a modern bug tracker

[Leo]

On 2008-01-08 23:49 +0000, Thien-Thi Nguyen wrote:
>   http://www.gnuvola.org/edb/edb-1.28p2.tar.gz
>
> the latter is a tarball that contains BUGS and BUGS.edb.
> BUGS.edb tells EDB the structure of BUGS.

Any plan to include edb in Emacs?

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/

Re: Why Emacs needs a modern bug tracker

[Thien-Thi Nguyen]

() Leo <sdl.web@gmail.com>
() Wed, 09 Jan 2008 01:13:04 +0000

   Any plan to include edb in Emacs?

maybe EDB 2.x (2008, fingers crossed).
EDB 1.x is extremely crufty.

thi

Re: Why Emacs needs a modern bug tracker

[Andrea Russo]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

>   http://www.gnuvola.org/edb/BUGS  <-- a living static
>                                        data base text file!
>
>   http://www.gnuvola.org/edb/edb-1.28p2.tar.gz

For anyone interested, I looked at those urls and found that the correct
ones are:

http://www.gnuvola.org/software/edb/BUGS

http://www.gnuvola.org/software/edb/edb-1.28p2.tar.gz

Regards,
Andrea.

--
L'acqua che tocchi de' fiumi e' l'ultima di quella che ando' e la prima
di quella che viene.  Cosi' il tempo presente.
		-- Leonardo da Vinci

Re: Why Emacs needs a modern bug tracker

[Thien-Thi Nguyen]

() Andrea Russo <rastandy@inventati.org>
() Wed, 09 Jan 2008 02:28:40 +0100

   For anyone interested, I looked at those urls
   and found that the correct ones are:

   http://www.gnuvola.org/software/edb/BUGS

   http://www.gnuvola.org/software/edb/edb-1.28p2.tar.gz

yes, you're right.  thanks for catching my mistake.

thi

Re: Why Emacs needs a modern bug tracker

[Alan Mackenzie]

Afternoon, Óscar!

On Sat, Jan 05, 2008 at 01:44:16AM +0100, Óscar Fuentes wrote:
> Alan Mackenzie <acm@muc.de> writes:

[ .... ]

> > I've worked many years in industry.  Bug databases done badly are
> > worse, much worse, than our email archive.

> X done badly is worse than not having X... this is a general
> justification for rejecting change, not for rejecting bad ideas.

Well....  Bug databases in companies tend to be done badly.  Some of the
forces that cause that might be present in free projects, so we need to
be very careful.

[ .... ]

> >> Now let's talk about user experience.

> >> *This* is where browser-centric interfaces become important.  I know
> >> from recent experience on Wesnoth and elsewhere that most users
> >> actually prefer using a well-designed web-based bug tracker to
> >> emailing bug reports.  For them, it *is* about the browser UI.  They
> >> find the structure and the sense of familiarity reassuring.

> > Right.  Eric, unplug your mouse and tell me how well-designed and
> > reassuringly familiar it is then.  I'm required to drive a bug
> > database (and other process abortions) by a grotty point and click
> > web interface 8 hours per working day at my day job, and I'm damned
> > if I'm going to come home and spend my playing time doing the same.
> [snip]

> I don't use point-and-click for filling web forms, keyboard works fine,
> thanks. See available solutions for your web browser. Even for filling
> text areas I use an utility that makes possible and convenient to do it
> with my favourite text editor.

I've never found a web browser good for anything other than browsing the
web.  I find filling in web forms so painful that I never do it unless I
can't avoid it.  Maybe getting the fields editable by Emacs would make it
tolerable.  We'll see.

> Really, it not as bad as you paint it, once you (and not your
> pointy-haired boss) are the one that controls the tools.

> > Like Richard said in another thread, we all have different
> > proclivities, and we _CHOOSE_ our tools to suit us.

> If we all have different proclivities, why we all use the same tools for
> developing Emacs?

Each of us have our own .emacs, some use a GUI, some text terminals, we
all use different mail clients, .....

> I guess this is because of consensus. You use CVS, although others may
> prefer Arch, and so on. The issue here is: are there better options?
> something that enhances our *overall* sense of gratification?

Supremely important is that the new tools must be customizable to suit
the way ANY of us work.

> See, DVCSs are great for working off-line, plus lots of other major
> advantages over CVS. However, the proposal had a cold response by
> precisely those who valuates working offline as essential. After
> reading RMS' replies I'm sure that if he works with a decent DVCS for a
> month, he will reject going back to CVS. Seriously.

Probably, so will I.

> Please keep an open mind.

I'm trying to be a counter-balancing force against those advocating
massive change.  

> > By the very nature of our product, we care deeply about the tools we
> > use.  Perhaps this is the real reason Emacs is still using email for
> > dealing with bugs, rather than a bug tracker with a suffocatingly
> > constrained web interface.

> Expressions like "suffocatingly constrained web interface" are too
> negative. Maybe you had a bad experience. I only can say that I wish
> Emacs' Customize forms were more web-form-alike.

I've had nothing but bad experience using web interfaces for anything but
web browsing (in its narrow sense).  "Suffocatingly constrained"
accurately describes what I feel about these interfaces.  A good
comparison is that of Info documentation vs. the reading the same manual
as html.  I don't want to be forced to use a web interface, even a
keyboard driven one, for reporting bugs.  I can't be alone.

> > How about this suggestion: the bug database should be administered by
> > our super-duper new distributed VCS, having its definitive version at
> > savannah.  Hackers will then update it by committing (?pushing) their
> > changes from their own local versions.  With these local versions,
> > they will have far more usable and flexible facilities than they
> > would over a lame http connection.

> I was thinking about this possibility and concluded that it is not
> possible to build a decent bug-tracking system using only a VCS. The
> reason is the importance of the user interface, which must be open to
> everybody, not only for the committers, as PROBLEMS and TODO are now,
> thus effectively dissuading possible contributions from the outside.

OK, VCS access IN ADDITION TO web access.  How about that?

> Furthermore, a bug-tracking system needs a database and a VCS is not
> good at that.

That is a good argument for staying with an email based system.  ;-(
What's the point of a bug system if you have to be online to use it?  It
kind of cancels out the benefit of a dVCS for our other files.

Are you telling me I won't be able to grep a bug-tracking database?  If
I'm using such a database, I want instant response when I press <CR> to
look at an item.  I want to be able to do M-x occur (or the like) on it,
without going through some ghastly GUI interface.  I want regexp
searching, filtering with a "command line"-like interface (e.g., like
mutt has), and so on.  And I want the database on my own hard disk, for
speed and flexibility.

> Oscar

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Why Emacs needs a modern bug tracker

[Alfred M. Szmidt]

   > Expressions like "suffocatingly constrained web interface" are
   > too negative. Maybe you had a bad experience. I only can say that
   > I wish Emacs' Customize forms were more web-form-alike.

   I've had nothing but bad experience using web interfaces for
   anything but web browsing (in its narrow sense).  "Suffocatingly
   constrained" accurately describes what I feel about these
   interfaces.  A good comparison is that of Info documentation
   vs. the reading the same manual as html.  I don't want to be forced
   to use a web interface, even a keyboard driven one, for reporting
   bugs.  I can't be alone.

You're not. "Suffocatingly constrained" describes such interfaces
quite well.

The nice thing about Emacs is that you have Emacs under your fingers.
And not another program that works so differently that you start
crying when you try to kill a region, you end up closing a tab with
unsaved data (e.g. firefox).

Or when you wish to save your bug report so you can send it later, no
can do with a web browser, in Emacs (or mutt) you could just save your
mail buffer for later editing and sending it when you feel you are
done.

And if something would crash during that session, you might just have
a auto-save file around, again, not something a web browser can do.

Re: Why Emacs needs a modern bug tracker

[Mike Mattie]

[-- Attachment #1.1: Type: text/plain, Size: 1786 bytes --]

On Sat,  5 Jan 2008 18:40:08 +0100 (CET)
"Alfred M. Szmidt" <ams@gnu.org> wrote:

>    > Expressions like "suffocatingly constrained web interface" are
>    > too negative. Maybe you had a bad experience. I only can say that
>    > I wish Emacs' Customize forms were more web-form-alike.
> 
>    I've had nothing but bad experience using web interfaces for
>    anything but web browsing (in its narrow sense).  "Suffocatingly
>    constrained" accurately describes what I feel about these
>    interfaces.  A good comparison is that of Info documentation
>    vs. the reading the same manual as html.  I don't want to be forced
>    to use a web interface, even a keyboard driven one, for reporting
>    bugs.  I can't be alone.
> 
> You're not. "Suffocatingly constrained" describes such interfaces
> quite well.
> 
> The nice thing about Emacs is that you have Emacs under your fingers.
> And not another program that works so differently that you start
> crying when you try to kill a region, you end up closing a tab with
> unsaved data (e.g. firefox).

I highly recommend firemacs. It's a firefox add-on that rebinds most
of the editing keys to Emacs defaults.

https://addons.mozilla.org/en-US/firefox/addon/4141

> Or when you wish to save your bug report so you can send it later, no
> can do with a web browser, in Emacs (or mutt) you could just save your
> mail buffer for later editing and sending it when you feel you are
> done.
> 
> And if something would crash during that session, you might just have
> a auto-save file around, again, not something a web browser can do.
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

    I highly recommend firemacs. It's a firefox add-on that rebinds most
    of the editing keys to Emacs defaults.

    https://addons.mozilla.org/en-US/firefox/addon/4141

I've been wanting that for ages.

Re: Why Emacs needs a modern bug tracker

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I highly recommend firemacs. It's a firefox add-on that rebinds most
>     of the editing keys to Emacs defaults.
>
>     https://addons.mozilla.org/en-US/firefox/addon/4141
>
> I've been wanting that for ages.

Place the line

gtk-key-theme-name = "Emacs"

into the file ~/.gtkrc-2.0 and that's basically it.  For all GTK+
applications, not just firefox.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Why Emacs needs a modern bug tracker

[Jan Djärv]

David Kastrup skrev:
> Richard Stallman <rms@gnu.org> writes:
> 
>>     I highly recommend firemacs. It's a firefox add-on that rebinds most
>>     of the editing keys to Emacs defaults.
>>
>>     https://addons.mozilla.org/en-US/firefox/addon/4141
>>
>> I've been wanting that for ages.
> 
> Place the line
> 
> gtk-key-theme-name = "Emacs"
> 
> into the file ~/.gtkrc-2.0 and that's basically it.  For all GTK+
> applications, not just firefox.
> 

Not guaranteed to work.  I think Gtk+ don't read ~/.gtkrc-2.0 if there is a 
gconf daemon running.  Or maybe that is a Gnome setup.  Anyway, Gtk+ 
developers says ~/.gtkrc-2.0 is depreciated.  Don't know how firefox does it 
though.  Anyway, the add on is useful for OSX and such also.

	Jan D.

Re: Why Emacs needs a modern bug tracker

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> David Kastrup skrev:
>> Richard Stallman <rms@gnu.org> writes:
>>
>>>     I highly recommend firemacs. It's a firefox add-on that rebinds most
>>>     of the editing keys to Emacs defaults.
>>>
>>>     https://addons.mozilla.org/en-US/firefox/addon/4141
>>>
>>> I've been wanting that for ages.
>>
>> Place the line
>>
>> gtk-key-theme-name = "Emacs"
>>
>> into the file ~/.gtkrc-2.0 and that's basically it.  For all GTK+
>> applications, not just firefox.
>>
>
> Not guaranteed to work.  I think Gtk+ don't read ~/.gtkrc-2.0 if there
> is a gconf daemon running.

In which case setting desktop/gnome/applications/interface/gtk_key_theme
to Emacs with gconf-editor should do the trick.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Why Emacs needs a modern bug tracker

[Jan Djärv]

David Kastrup skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> David Kastrup skrev:
>>> Richard Stallman <rms@gnu.org> writes:
>>>
>>>>     I highly recommend firemacs. It's a firefox add-on that rebinds most
>>>>     of the editing keys to Emacs defaults.
>>>>
>>>>     https://addons.mozilla.org/en-US/firefox/addon/4141
>>>>
>>>> I've been wanting that for ages.
>>> Place the line
>>>
>>> gtk-key-theme-name = "Emacs"
>>>
>>> into the file ~/.gtkrc-2.0 and that's basically it.  For all GTK+
>>> applications, not just firefox.
>>>
>> Not guaranteed to work.  I think Gtk+ don't read ~/.gtkrc-2.0 if there
>> is a gconf daemon running.
> 
> In which case setting desktop/gnome/applications/interface/gtk_key_theme
> to Emacs with gconf-editor should do the trick.
> 

On my install, that is desktop/gnome/interface/gtk_key_theme.  I guess it can 
not hurt to set it in both places (and ~/.gtkrc-2.0).

	Jan D.

Re: Why Emacs needs a modern bug tracker

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> David Kastrup skrev:
>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>
>>> David Kastrup skrev:
>>>> Richard Stallman <rms@gnu.org> writes:
>>>>
>>>>>     I highly recommend firemacs. It's a firefox add-on that rebinds most
>>>>>     of the editing keys to Emacs defaults.
>>>>>
>>>>>     https://addons.mozilla.org/en-US/firefox/addon/4141
>>>>>
>>>>> I've been wanting that for ages.
>>>> Place the line
>>>>
>>>> gtk-key-theme-name = "Emacs"
>>>>
>>>> into the file ~/.gtkrc-2.0 and that's basically it.  For all GTK+
>>>> applications, not just firefox.
>>>>
>>> Not guaranteed to work.  I think Gtk+ don't read ~/.gtkrc-2.0 if there
>>> is a gconf daemon running.
>>
>> In which case setting desktop/gnome/applications/interface/gtk_key_theme
>> to Emacs with gconf-editor should do the trick.
>
> On my install, that is desktop/gnome/interface/gtk_key_theme.

Uh, in my install as well.  I was just too stupid to interpret the
collapsing menus correctly.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Why Emacs needs a modern bug tracker

[Bill Wohler]

Richard Stallman <rms@gnu.org> writes:

>     I highly recommend firemacs. It's a firefox add-on that rebinds most
>     of the editing keys to Emacs defaults.
>
>     https://addons.mozilla.org/en-US/firefox/addon/4141
>
> I've been wanting that for ages.

See also the Firefox It's All Text add-on which allows you to use
emacsclient to edit text areas.

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

Re: Why Emacs needs a modern bug tracker

[Giorgos Keramidas]

On 2008-01-06 13:09, Richard Stallman <rms@gnu.org> wrote:
>     I highly recommend firemacs. It's a firefox add-on that rebinds most
>     of the editing keys to Emacs defaults.
>
>     https://addons.mozilla.org/en-US/firefox/addon/4141
>
> I've been wanting that for ages.

Hi Richard,
Another extension which you will probably like a lot is `mozex':

  http://mozex.mozdev.org/development.html

It can be configured to allow editing of web forms through emacsclient,
which I *always* do these days.  I vehemently _hate_ having to edit in a
tiny text box, with web-page dependent fonts and non-Emacs keyboard
bindings.  So I usually install mozex, and then configure mozex to edit
text areas with:

    emacsclient -a emacs

I commonly start `server-mode' in an Emacs instance when I fire up X11,
so this works quite nicely.

Re: Why Emacs needs a modern bug tracker

[Robert J. Chassell]

Please remember, some are not connected to the Internet except
occasionally.  Some live 12 hours opposite others.

And there are some who are continuously connected and in your time
zone who do not want to use Emacs W3 mode (or W3M mode, which is not
available to everyone), which is to say, they don't want to use a Web
browser, not even a non-Emacs Web browser.  They prefer to have
important materials electronically mailed to them.

You have to be able to wait at least 2 and perhaps 3 days,
occasionally longer.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Why Emacs needs a modern bug tracker

[Robert J. Chassell]

Every day or two, occasionally longer, I update my Emacs and test it.
Also, I receive mail to emacs-devel@gnu.org.  I am looking forward to
seeing an increase in the number of significant bug reports sent to
emacs-devel@gnu.org.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

[snip]

> Supremely important is that the new tools must be customizable to suit
> the way ANY of us work.

Even for the small team of regular committers, I doubt all of you are
100% happy with the tools you are using and would prefer something else
for some task.

The problem with refusing to give up a bit of your comfort is that you
may produce an uncomfortable environment for others. IMHO, one of the
problems with Emacs is its failure attracting new hackers.

It is clear to me that a DVCS would make Emacs hacking more fun for
current project members, and a good bug tracker would be very useful and
just a little bit annoying for you. With this facilities, from the
outside, Emacs would appear as a more open and participative project.

[snip]

>> I was thinking about this possibility and concluded that it is not
>> possible to build a decent bug-tracking system using only a VCS. The
>> reason is the importance of the user interface, which must be open to
>> everybody, not only for the committers, as PROBLEMS and TODO are now,
>> thus effectively dissuading possible contributions from the outside.
>
> OK, VCS access IN ADDITION TO web access.  How about that?

Others just proposed such a system. I'm skeptical about it. So far, it
seems quite limiting and for a good reason:

>> Furthermore, a bug-tracking system needs a database and a VCS is not
>> good at that.
>
> That is a good argument for staying with an email based system.  ;-(
> What's the point of a bug system if you have to be online to use it?  It
> kind of cancels out the benefit of a dVCS for our other files.
>
> Are you telling me I won't be able to grep a bug-tracking database?  If
> I'm using such a database, I want instant response when I press <CR> to
> look at an item.  I want to be able to do M-x occur (or the like) on it,
> without going through some ghastly GUI interface.  I want regexp
> searching, filtering with a "command line"-like interface (e.g., like
> mutt has), and so on.  And I want the database on my own hard disk, for
> speed and flexibility.

You can request a plain-text export of the database.

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Lennart Borgman (gmail)]

Óscar Fuentes wrote:
>>> I was thinking about this possibility and concluded that it is not
>>> possible to build a decent bug-tracking system using only a VCS. The
>>> reason is the importance of the user interface, which must be open to
>>> everybody, not only for the committers, as PROBLEMS and TODO are now,
>>> thus effectively dissuading possible contributions from the outside.
>> OK, VCS access IN ADDITION TO web access.  How about that?
> 
> Others just proposed such a system. I'm skeptical about it. So far, it
> seems quite limiting and for a good reason:

I do not get your point here. Can you explain why you are skeptical and 
why you think it would be limiting in another way?

>>> Furthermore, a bug-tracking system needs a database and a VCS is not
>>> good at that.
>> That is a good argument for staying with an email based system.  ;-(
>> What's the point of a bug system if you have to be online to use it?  It
>> kind of cancels out the benefit of a dVCS for our other files.
>>
>> Are you telling me I won't be able to grep a bug-tracking database?  If
>> I'm using such a database, I want instant response when I press <CR> to
>> look at an item.  I want to be able to do M-x occur (or the like) on it,
>> without going through some ghastly GUI interface.  I want regexp
>> searching, filtering with a "command line"-like interface (e.g., like
>> mutt has), and so on.  And I want the database on my own hard disk, for
>> speed and flexibility.
> 
> You can request a plain-text export of the database.
> 

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Óscar Fuentes wrote:
>>>> I was thinking about this possibility and concluded that it is not
>>>> possible to build a decent bug-tracking system using only a VCS. The
>>>> reason is the importance of the user interface, which must be open to
>>>> everybody, not only for the committers, as PROBLEMS and TODO are now,
>>>> thus effectively dissuading possible contributions from the outside.
>>> OK, VCS access IN ADDITION TO web access.  How about that?
>>
>> Others just proposed such a system. I'm skeptical about it. So far, it
>> seems quite limiting and for a good reason:
>
> I do not get your point here. Can you explain why you are skeptical
> and why you think it would be limiting in another way?

Because of this:

>>>> Furthermore, a bug-tracking system needs a database and a VCS is not
>>>> good at that.

A VCS provides a filesystem to work on, not a database.

A bug tracker based on a VCS wouldn't provide more that what we can
achieve now with FOR-RELEASE, TODO, etc.

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Stefan Monnier]

>>>>> I was thinking about this possibility and concluded that it is not
>>>>> possible to build a decent bug-tracking system using only a VCS. The
>>>>> reason is the importance of the user interface, which must be open to
>>>>> everybody, not only for the committers, as PROBLEMS and TODO are now,
>>>>> thus effectively dissuading possible contributions from the outside.
>>>> OK, VCS access IN ADDITION TO web access.  How about that?
>>> 
>>> Others just proposed such a system. I'm skeptical about it. So far, it
>>> seems quite limiting and for a good reason:
>> 
>> I do not get your point here. Can you explain why you are skeptical
>> and why you think it would be limiting in another way?

> Because of this:

>>>>> Furthermore, a bug-tracking system needs a database and a VCS is not
>>>>> good at that.

> A VCS provides a filesystem to work on, not a database.

> A bug tracker based on a VCS wouldn't provide more that what we can
> achieve now with FOR-RELEASE, TODO, etc.

I think you're confusing things a little: the database should be inside
a file like TODO which is itself managed via a VCS (actually the file
needs to be alongside the rest of the code).  This way when we merge the
unicode branch into the trunk (for instance), the unicode-branch bugs
database will "automatically" get merged into the trunk's bugs database.


        Stefan

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

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

>> A VCS provides a filesystem to work on, not a database.
>
>> A bug tracker based on a VCS wouldn't provide more that what we can
>> achieve now with FOR-RELEASE, TODO, etc.
>
> I think you're confusing things a little: the database should be inside
> a file like TODO which is itself managed via a VCS (actually the file
> needs to be alongside the rest of the code).  This way when we merge the
> unicode branch into the trunk (for instance), the unicode-branch bugs
> database will "automatically" get merged into the trunk's bugs database.

I'll like to have such a system. I was thinking how to build it and
concluded that it would work for a small project (i.e. with a few
developers) with a few or no users reporting bugs. Then, there are some
inconveniences, like what to do with clashes (when two users changes the
same field of the same report, something you won't discover until you
merge their changes), how to do queries like "reports opened on last 30
days" and some other things that can't remember right now, but maybe
everything is counterbalanced by the convenience it brings for those who
work offline.

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Bastien]

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

>> A VCS provides a filesystem to work on, not a database.
>
>> A bug tracker based on a VCS wouldn't provide more that what we can
>> achieve now with FOR-RELEASE, TODO, etc.
>
> I think you're confusing things a little: the database should be inside
> a file like TODO which is itself managed via a VCS (actually the file
> needs to be alongside the rest of the code).

Hence my proposal of using `org-mode' instead of `outline-mode' as the
default mode for TODO, FOR-RELEASE and other such files.

There will be no loss in functionnality.  The right Org setup for these
files will be incrementally defined, by people really using them.

You can invent clever uses of org-mode to turn them into real databases:
Org turns plain text files into browsable, searchable, structured files.
And once these files are managed via a dVCS, this can really be used as
a collective tool for managing bugs and issues.

This will not replace a public bug tracking system, but this will still
improve the situtation significantly IMO.

-- 
Bastien

Re: Why Emacs needs a modern bug tracker

[Eric S. Raymond]

Alan Mackenzie <acm@muc.de>:
>       I think RMS can and does keep well abreast of the bug status,
> even though I wouldn't be able to with just email.

Maybe you're right.  But (a) RMS isn't going to do that job forever,
and (b) even he were eternally available, the project has better uses
for his brain than the donkey-work of carrying around all that issue
state.  I for one would rather see that energy spent on creation.

> I don't think we want to do several major releases per year.

I don't think we do either,  But several minor releases would be 
a good idea, if only to counter the widespread perception that the
project is sclerotic.

> I've worked many years in industry.  Bug databases done badly are worse,
> much worse, than our email archive.

Granted.  But we have the talent and tools to do it right.
 
> Talking of which: however we collect bug reports, we will need moderation
> of some sort to exclude spam.  Can we take it that this is a solved
> problem?

I've never seen spam on the Wesnoth bugtracker.  It does include a feature
that allows the first responder on a bug to flag it as spam.  I presume
it is then excluded from the normal view.

If emacs-bugs doesn't already have a spam problem, a tracker isn't 
likely to either.

> If they're pure web, I doubt they'll be accepted by the hackers here,
> who're accustomed to Emacs-quality interfaces.  Whatever we decide on
> must be usable from a normal Emacs buffer.

There's emacs-bug to be hacked.  And one of our listmembers has
already noted that the Debian tracker can be driven by email.

> Also, the fields in these forms must be kept under as tight control as a
> camp fire in a drought stricken forest.  4 or 5 fields are OK.  8 to 10
> are pushing the boundary.  Let a QA department into the works, and before
> you know it you've got upwards of 100 largely meaningless fields, so that
> said QA "can accurately monitor the trends and problems of the developers
> and tune the company's processes accordingly".

This is true.  You'll be reassured, perhaps, to know that the
evolutionary direction in bug trackers has been to simplify, simplify,
simplify.  The original Bugzilla was exactly the sort of nightmare you
describe, and I refused to have anything to do with it.  More recent
ones like the Ubuntu and Gna! bug trackers are quite lightweight 
and pleasant by comparison.

> I disagree.  An email bug entry system is necessary, and should perhaps
> be the preferred method, with a web form as an alternative.  This email
> will of course be structured.  M-x report-emacs-bug or C-c C-b (in a CC
> Mode buffer) could be enhanced easily enough.

Like I said, emacs-bug.  It's *unstructured* mail that has to be
deprecated.
 
> Hmmm.  I hope that's not as contumelious as it sounds.  That "allow" had 
> better be a first class interface, not just a second rate crock intended
> to keep us "outmoded grandads" from moaning.

Write it.  Then you'll know it's correct.

> How about this suggestion: the bug database should be administered by our
> super-duper new distributed VCS, having its definitive version at
> savannah.  Hackers will then update it by committing (?pushing) their
> changes from their own local versions.  With these local versions, they
> will have far more usable and flexible facilities than they would over a
> lame http connection.

No good.  You're ignoring the *users*.  Remember users...you know, he people
the reporting emd of a tracker is actually *for*?  They don't want to futz with 
some geek's wet dream of "flexibilty".  They want web forms.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Why Emacs needs a modern bug tracker

[Alan Mackenzie]

Hi, Eric!

On Sat, Jan 05, 2008 at 12:20:07AM -0500, Eric S. Raymond wrote:
> Alan Mackenzie <acm@muc.de>:

[ .... ]

> > I've worked many years in industry.  Bug databases done badly are
> > worse, much worse, than our email archive.

> Granted.  But we have the talent and tools to do it right.

OK, we're agreed!  There was something in your posting which suggested
the notion that merely using such tools would be the Right Thing.  We
need to use them well, too.

[ .... ]

> > If they're pure web, I doubt they'll be accepted by the hackers here,
> > who're accustomed to Emacs-quality interfaces.  Whatever we decide on
> > must be usable from a normal Emacs buffer.

> There's emacs-bug to be hacked.  And one of our listmembers has
> already noted that the Debian tracker can be driven by email.

What is "emacs-bug"?  I think I'm missing some context somewhere.

> > Also, the fields in these forms must be kept under as tight control
> > as a camp fire in a drought stricken forest.  4 or 5 fields are OK.
> > 8 to 10 are pushing the boundary.  Let a QA department into the
> > works, and before you know it you've got upwards of 100 largely
> > meaningless fields, so that said QA "can accurately monitor the
> > trends and problems of the developers and tune the company's
> > processes accordingly".

> This is true.  You'll be reassured, perhaps, to know that the
> evolutionary direction in bug trackers has been to simplify, simplify,
> simplify.  The original Bugzilla was exactly the sort of nightmare you
> describe, and I refused to have anything to do with it.  More recent
> ones like the Ubuntu and Gna! bug trackers are quite lightweight and
> pleasant by comparison.

The best (proprietary) bug tracker I ever used had fields only for things
like person creating the entry, status (open/fixed/rejected), customer,
severity, urgency.  Then it had free text areas for describing the bug.

> > I disagree.  An email bug entry system is necessary, and should
> > perhaps be the preferred method, with a web form as an alternative.
> > This email will of course be structured.  M-x report-emacs-bug or C-c
> > C-b (in a CC Mode buffer) could be enhanced easily enough.

> Like I said, emacs-bug.  It's *unstructured* mail that has to be
> deprecated.

Deprecated or enhanced?  ;-)

> > Hmmm.  I hope that's not as contumelious as it sounds.  That "allow"
> > had better be a first class interface, not just a second rate crock
> > intended to keep us "outmoded grandads" from moaning.

> Write it.  Then you'll know it's correct.

Fair response.  ;-)  But the base system has to be one that allows
appropriate access.  A mail archive allows searching by all of mutt's
handy operators.  You can even grep the raw mailbox archive (yes, this IS
useful, even though you only need to do this occasionally).  My fear is
that the new bug tracker will be restricted to what its designers thought
was "all that you need"; or that I'll have to go through a ghastly point
and click "create a query" interface, like I had to yesterday at work.

> > How about this suggestion: the bug database should be administered by
> > our super-duper new distributed VCS, having its definitive version at
> > savannah.  Hackers will then update it by committing (?pushing) their
> > changes from their own local versions.  With these local versions,
> > they will have far more usable and flexible facilities than they
> > would over a lame http connection.

> No good.  You're ignoring the *users*.  Remember users...you know, he
> people the reporting emd of a tracker is actually *for*?  They don't
> want to futz with some geek's wet dream of "flexibilty".  They want web
> forms.

I wasn't very clear, there.  Of course users need web forms, and they
will manipulate the database directly.  But why can't we have VCS
updating, too?  This will allow RMS and others to work offline, a very
desirable thing.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Why Emacs needs a modern bug tracker

[Eric S. Raymond]

Alan Mackenzie <acm@muc.de>:
> > There's emacs-bug to be hacked.  And one of our listmembers has
> > already noted that the Debian tracker can be driven by email.
> 
> What is "emacs-bug"?  I think I'm missing some context somewhere.

Perhaps I have the name wrong, but I believe there is an Emacs mode
specifically for generating bug reports to be mailed in.  I think
I used it once.
 
> The best (proprietary) bug tracker I ever used had fields only for things
> like person creating the entry, status (open/fixed/rejected), customer,
> severity, urgency.  Then it had free text areas for describing the bug.

That's about where the Wesnoth and Ubuntu trackers are.  The Wesnoth one 
does have a "platform" field for specifying your OS, but that's
reasonable given that we do both Mac and Windows ports.

> Fair response.  ;-)  But the base system has to be one that allows
> appropriate access.

This is *not difficult*.  There's not even any need to postulate other than 
HTTP access to do it, because we have w3m.

If all else fails, we write a mode that uses w3m to presents a bug-entry or
query form and then does a transaction with the bug-tracker CGI.  I'll
bet either you or I could throw that together in a few hours' work.

> I wasn't very clear, there.  Of course users need web forms, and they
> will manipulate the database directly.  But why can't we have VCS
> updating, too?  This will allow RMS and others to work offline, a very
> desirable thing.

A VCS-based solution would be more complicated than necessary. Easier
just to write a w3m-based client that pulls a copy of the entire bug 
database out of the tracker.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Why Emacs needs a modern bug tracker

[Lennart Borgman (gmail)]

Eric S. Raymond wrote:
>> I wasn't very clear, there.  Of course users need web forms, and they
>> will manipulate the database directly.  But why can't we have VCS
>> updating, too?  This will allow RMS and others to work offline, a very
>> desirable thing.
> 
> A VCS-based solution would be more complicated than necessary. Easier
> just to write a w3m-based client that pulls a copy of the entire bug 
> database out of the tracker.

Just a detail and nothing to discuss now: w3m is not available 
everywhere. Maybe the url libraries in Emacs can be used though.

Re: Why Emacs needs a modern bug tracker

[Eric S. Raymond]

Lennart Borgman (gmail) <lennart.borgman@gmail.com>:
>> A VCS-based solution would be more complicated than necessary. Easier
>> just to write a w3m-based client that pulls a copy of the entire bug 
>> database out of the tracker.
>
> Just a detail and nothing to discuss now: w3m is not available everywhere. 
> Maybe the url libraries in Emacs can be used though.

Friendly amendment accepted.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Why Emacs needs a modern bug tracker

[Chris Ball]

Hi,

   >> I wasn't very clear, there.  Of course users need web forms, and
   >> they will manipulate the database directly.  But why can't we have
   >> VCS updating, too?  This will allow RMS and others to work
   >> offline, a very desirable thing.

   > A VCS-based solution would be more complicated than
   > necessary. Easier just to write a w3m-based client that pulls a
   > copy of the entire bug database out of the tracker.

Just for the record, DVCS-based bug databases *do* exist, and allow the
offline working we're looking for while also allowing a user-friendly
web-based interface.  The two interfaces can exist without friction --
it's a distributed VCS, and the web interface becomes just one more
repository performing push and pull operations on the master database.

One such bugtracker is "Bugs Everywhere":

   http://www.panoramicfeedback.com/opensource/index.html

I think it's appealing to have a checkout of the bug database available
alongside a source code checkout.  Bugs Everywhere is not finished yet,
but can use many different VCS backends including arch, bzr and hg.
I have a small patch to add GIT support to it, too.

   http://dev.laptop.org/~cjb/libbe-git.patch

It's great to see a discussion about workflow improvements happening
here.  I'd like to help if I can.

- Chris.
-- 
Chris Ball   <cjb@laptop.org>

Re: Why Emacs needs a modern bug tracker

[Lennart Borgman (gmail)]

Chris Ball wrote:
> Just for the record, DVCS-based bug databases *do* exist, and allow the
> offline working we're looking for while also allowing a user-friendly
> web-based interface.  The two interfaces can exist without friction --
> it's a distributed VCS, and the web interface becomes just one more
> repository performing push and pull operations on the master database.
> 
> One such bugtracker is "Bugs Everywhere":
> 
>    http://www.panoramicfeedback.com/opensource/index.html


Can it send out emails when something changes?

Re: Why Emacs needs a modern bug tracker

[Eric S. Raymond]

Chris Ball <cjb@laptop.org>:
> Just for the record, DVCS-based bug databases *do* exist, and allow the
> offline working we're looking for while also allowing a user-friendly
> web-based interface.  The two interfaces can exist without friction --
> it's a distributed VCS, and the web interface becomes just one more
> repository performing push and pull operations on the master database.
> 
> One such bugtracker is "Bugs Everywhere":
> 
>    http://www.panoramicfeedback.com/opensource/index.html
> 
> I think it's appealing to have a checkout of the bug database available
> alongside a source code checkout.  Bugs Everywhere is not finished yet,
> but can use many different VCS backends including arch, bzr and hg.
> I have a small patch to add GIT support to it, too.

This sounds interesting.  How close would you say it is to production status?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Why Emacs needs a modern bug tracker

[Stephen J. Turnbull]

Eric S. Raymond writes:

 > > I think it's appealing to have a checkout of the bug database available
 > > alongside a source code checkout.  Bugs Everywhere is not finished yet,
 > > but can use many different VCS backends including arch, bzr and hg.
 > > I have a small patch to add GIT support to it, too.
 > 
 > This sounds interesting.  How close would you say it is to production status?

Interesting, yes, but a word of caution: a bug database is like a
market.  Markets are most useful when *every* bid and ask is
published.  As soon as you allow secret dealing, things become less
liquid.  Similarly, unless bugs are more or less automatically pushed
to the public interface, it's not going to be as useful for
communicating with casual users and developers.  The easiest and least
invasive way to achieve automatic pushing is to have only the public
interface for bug entry.

Of course the motivations for "secrecy" are personal profit in the
market and "laziness" in the bug tracker, but the chilling effects on
information flow will be qualitatively similar.  Quantitatively?  "Try
it and see."  But be prepared with Plan B.

email-based development (was:: Why Emacs needs a modern bug tracker)

[John S. Yates, Jr.]

On Sat, 05 Jan 2008 14:58:13 -0500, Chris Ball wrote:

> One such bugtracker is "Bugs Everywhere":
>
>     http://www.panoramicfeedback.com/opensource/index.html

BugEverywhere is the work of Aaron Bentley, a member of the
bzr development team.  Bzr has a very email-centric workflow
that should be studied if only to get a sense of what is
possible.  The project shares some of the attributes that ESR
has advocated but with a greater emphasis on a formalized
email-based workflow:

  http://people.ubuntu.com/~ianc/doc/en/developer-guide/HACKING.html

Some tooling links:

  http://code.aaronbentley.com/bundlebuggy/
  https://launchpad.net/pqm

/john

Let a QA department into the works

[Andreas Röhler]

From Re: Why Emacs needs a modern bug tracker

Am Samstag, 5. Januar 2008 00:25 schrieb Alan Mackenzie:
> Hi, Eric!
>
> On Fri, Jan 04, 2008 at 11:44:54AM -0500, Eric S. Raymond wrote:
>
> [ .... ]
>
  Let a QA department into the works, and before
> you know it you've got upwards of 100 largely meaningless fields, so that
> said QA "can accurately monitor the trends and problems of the developers
> and tune the company's processes accordingly".
>



AFAIU the way Emacs is developed is still very the same
RMS described the start at MIT: programmers join the
code they use and like.

There is nothing wrong with that, as we have and enjoy
Emacs finally.

However, as far as the world of non-programmers is
touched, some short-comings are obvious:

Entering Emacs from a common
writers/translaters/publishers life, it took me hours
if not days of desperate searching to realize:
text-mode has no foot-note facilities integrated.

Having heard from Emacs as an editor with capabilities I
simply couldn't imagine that, searched the doku over
and over. (Please don't forget, while starting, you'll
make a lot of stupid errors too, being aware of
that. So people will not adress help groups in this
state of affair, rather abondon the tool.)

Footnotes here is simply an expample, I could list a
couple of more things.

Well, you could decide: let Emacs stay a born of joy
for programmers and programmers only. Than distributors
should tell that more clearly than its done now.

Or it's said: We will have Emacs as a general editing
tool. Than the needs of none-programmers should be
studied in a systematic manner.

To understand the needs of people of a different kind
is a difficult task, as psychologists or ethnography
may explain. It's a hard task as programming
itself. Probably the help of experts for this will be
required.

From there the need for such an expert heading a QA
group, with some authority to make decisions how to
proceed.

Grüße

Andreas Röhler

Re: Let a QA department into the works

[Eli Zaretskii]

> From: Andreas =?iso-8859-1?q?R=F6hler?= <andreas.roehler@online.de>
> Date: Sat, 5 Jan 2008 09:51:20 +0100
> 
> Entering Emacs from a common
> writers/translaters/publishers life, it took me hours
> if not days of desperate searching to realize:
> text-mode has no foot-note facilities integrated.

How would that task (which I admit is hard for _any_ newcomer to _any_
sophisticated software package) be helped by whatever changes to the
Emacs maintenance are considered in this and other related threads?

Re: Let a QA department into the works

[Richard Stallman]

    Entering Emacs from a common
    writers/translaters/publishers life, it took me hours
    if not days of desperate searching to realize:
    text-mode has no foot-note facilities integrated.

Most of the time when people use footnotes they do so
in text that is marked up (LaTeX, Texinfo, nroff).
Would it be useful to add footnote commands to the corresponding modes?

Re: Let a QA department into the works

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Entering Emacs from a common
>     writers/translaters/publishers life, it took me hours
>     if not days of desperate searching to realize:
>     text-mode has no foot-note facilities integrated.
>
> Most of the time when people use footnotes they do so in text that is
> marked up (LaTeX, Texinfo, nroff).  Would it be useful to add footnote
> commands to the corresponding modes?

M-x load-library RET footnote RET

Maybe its keybindings should be preloaded.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Let a QA department into the works

[Andreas Röhler]

Am Sonntag, 6. Januar 2008 12:15 schrieb David Kastrup:
> Richard Stallman <rms@gnu.org> writes:
> >     Entering Emacs from a common
> >     writers/translaters/publishers life, it took me hours
> >     if not days of desperate searching to realize:
> >     text-mode has no foot-note facilities integrated.
> >
> > Most of the time when people use footnotes they do so in text that is
> > marked up (LaTeX, Texinfo, nroff).  Would it be useful to add footnote
> > commands to the corresponding modes?
>
> M-x load-library RET footnote RET
>
> Maybe its keybindings should be preloaded.

With text-mode footnote-mode should be present per
default IMO.

BTW

footnote.el says:

,----
| ;; This file provides footnote[1] support for message-mode in emacsen.
`----

That's not correct in this context.

Too footnote.el is buggy as it doesn't detect already
existing footnotes. Had delivered a footnote-init.el
already.


Andreas Röhler

Re: Why Emacs needs a modern bug tracker

[Bastien]

Alan Mackenzie <acm@muc.de> writes:

>> The good thing about bug-tracker web forms from a developer point of
>> view isn't really that they're web, it's that they're *forms*. You can
>> channel your users into identifying the platform they're running on,
>> the preceived bug severity, and half a dozen other search keys.
>
> If they're pure web, I doubt they'll be accepted by the hackers here,
> who're accustomed to Emacs-quality interfaces.  Whatever we decide on
> must be usable from a normal Emacs buffer.

I'm surprised nobody mentionned org.el in this discussion yet.

From Org's manual:

  Org-mode is a mode for keeping notes, maintaining TODO lists, and
  doing project planning with a fast and effective plain-text system.

Instead of switching to a full-blown bug tracking system, I think we
could first try to improve the way information is currently stored in
emacs/etc/TODO or emacs/etc/PROBLEMS or related files[1].

For now, these two files use outline-mode.  Since org-mode is really
"outline-mode made (more) useful", the upgrade is straightforward.

Here's how Org would help:

1. Org can be used as a *database*, since each item can be associated
   with pairs of property-value.  Org provides very useful features to
   _visualize_ properties (info "(org)Column View") and to _search_ for
   items with specific properties (info "(org)Property searches").

2. Org can easily cooperate with email based development.  Linking to an
   email is just one keystroke away, should this link show the email via
   rmail, Gnus, or a webpage on Gmane.  `report-emacs-bug' is structured
   enough to be easily converted into an Org entry.

3. org-mode is an Emacs mode, hence I suspect many Emacs developpers
   around there will love it (more than any bug tracking system...)

4. You can export Org files to HTML, letting everybody read them through
   a web browser.

5. Org files are plain text files, hence they are fully searchable.

My point here is that using Org would gradually improve the way people
work together without breaking anything in the current system.

Notes: 

[1]  Of course, having better TODO and PROBLEMS files does not help when
     it comes to let users send bug reports.  But making things easier
     for the developers and making things easiers for the users are two
     distincts issues, which may be addressed with distinct tools.

-- 
Bastien

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

    I think Stefan is expressing a view that is pretty common among the
    old-school Emacs devs here.  Alas, I think it's quite far out of
    touch with the reality of 2008.

That is an insulting way to present your suggestions.  If you want
your suggestions to be considered, please dont make them offensive.
I won't give in to bullying.

Re: Why Emacs needs a modern bug tracker

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
>     I think Stefan is expressing a view that is pretty common among the
>     old-school Emacs devs here.  Alas, I think it's quite far out of
>     touch with the reality of 2008.
> 
> That is an insulting way to present your suggestions.  If you want
> your suggestions to be considered, please dont make them offensive.
> I won't give in to bullying.

Er...would you prefer I began lying to you, then?

If you insist, I could write things like "Yes!  Yes!  The assumptiona
and practices of 1993 are still *totally appropriate* in 2008, more
than a decade after the big WWW buildout.  Project scales haven't
changed, and there have been no improvements in our tools worth
noticing or incorporating."

But it wouldn't be true, and it wouldn't be helpful. And all you can
possibly accomplish by categorizing my behavior as "bullying" is to
train anyone watching the exchange to lie to you rather than bringing
you actual news of the outside world.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

    > That is an insulting way to present your suggestions.  If you want
    > your suggestions to be considered, please dont make them offensive.
    > I won't give in to bullying.

    Er...would you prefer I began lying to you, then?

Please recognize the difference between presenting your opinions
in a civil tone and pretending to have other opinions.

    If you insist, I could write things like "Yes!  Yes!  The assumptiona
    and practices of 1993 are still *totally appropriate* in 2008, more
    than a decade after the big WWW buildout.

You are welcome to say you think that a change is needed, as long
as you do it without insulting those who might disagree with you.

Re: Why Emacs needs a modern bug tracker

[Eli Zaretskii]

> From: "Eric S. Raymond" <esr@snark.thyrsus.com>
> Date: Fri,  4 Jan 2008 11:44:54 -0500 (EST)
> 
> The difference is scale.  GPSD is about 60K lines of code, with a
> COCOMO estimate of about 14.2 person-years and about 3 active
> developers; normally we only have three or four issues active at once.
> Wesnoth is a hair over 100K lines, with a COCOMO estimate of 25.6
> years and 10-12 active developers; over the last year we've gone from
> about 500 issues tracked to a bit over 300 (currently 196 feature requests,
> 89 bugs, and the remainder marked Fixed but not yet purged).
> 
> Somewhere in the scale range between GPSD and Wesnoth, having an issue
> tracker moves from being a dispensable luxury to being an extremely
> important tool. [...]
> 
> Now I consider Emacs: 1100K lines, a COCOMO estimate of over 328
> years, and no issue database. I think I think I understand much better
> now now why the team has only been able to ship one release in five years.
> Trying to converge on a releasable state with as poor a view of the
> Emacs bug load as we have must be damn near impossible.

You are implicitly assuming here that what is good for a COCOMO-25
project and 10-12 active developers should be also good for a
COCOMO-328 project with fewer than 10 developers.  Do you have any
evidence that this assumption is true, or arguments that would tell me
such an assumption is reasonable?

> One of the places a real issue database is most concretely useful is when
> you're triaging bugs to close on a release.  It is *immensely* helpful
> in making clear what needs to be done and at what point you are
> finished doing it.

In Emacs development, we have problems to even find a release manager,
let alone someone who will replace Richard as a head maintainer.  So
having a bug triage system that is significantly better that a flat
text file such as admin/FOR-RELEASE is not necessarily the first
priority here.

Emacs is HUGE.  Its immense size is not the only problem: there are
many parts in it that require experts in specific areas (GUI display,
networking, Lisp infrastructure, email, multilingual text editing, to
name just a random few) in order to know what is right and wrong when
reviewing patches.  Just figuring out how best to organize maintenance
of such a large package is a daunting task, to say nothing of actually
implementing such a maintenance scheme (which would mean finding and
recruiting individuals who could become part of such a team, then
making a coherent and cooperative team out of them).  It is IMO naive
at best to think that switching to more collaborative tools would
somehow magically solve these _real_ problems, or even pave a way for
their _practical_ solution.

Re: Why Emacs needs a modern bug tracker

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> You are implicitly assuming here that what is good for a COCOMO-25
> project and 10-12 active developers should be also good for a
> COCOMO-328 project with fewer than 10 developers.  Do you have any
> evidence that this assumption is true, or arguments that would tell me
> such an assumption is reasonable?

Yes, I think I do.  Let's consider some of the scaling curves.

First, the size of a project's bug load is driven by the square of
LOC.  This is because most bugs are clashes between assumptions mode
in differing parts of the code.  Modularization can reduce such
clashes, but it's basically unheard of to get *quadratic* reduction,
especially on large old codebases; the best you can really hope for 
is a linear reduction (cf Clark and Baldwin's "Design Rules", 1999).

The utility of a tracker is (at least) proportional to the size of the
bug load, because one of its functions is to help identify the N most
critical bugs at any given time.  Arguably it's proportional to the
*square* of the bug load -- one of its other uses is to identify and
record bug interdependencies.

Therefore: best case, tracker utility TL rises as the square of LOC,
Worst case, it rises as the fourth power of LOC. This would neatly
explain why the jump from 60K lines to only 100K puts GPSD and Wesnoth
in regimes that are qualitatively different.

(For what it's worth, my own belief is that bug interdependencies have
the statistics of a scale-free network.  I can explain why in detail if
you care; it goes back to Ross Anderson's papers applying statistical
thermodynamics to model bug distribution in large systems. In that
case the actual utility curve of the tracker is somewhere between
LOC**2 and LOC**4, at about (LOC**2/k) * log(LOC**2/k) where k is a
constant measuring the degree of modularity in the code.  LOC**2 will
underestimate this substantially unless k is absurdly large.)

But to be as friendly as possible to your skepticism we'll set the utility 
function TL(LOC) = m * LOC**2, for m an unknown constant.

Now, remember that the LOC ratio we're talking about is 10:1.  That
means that, best case for your skepticism, a tracker should be O(10**2)
times as valuable to Emacs as it is to Wesnoth assuming we hold the
number of developers for both projects to the same constant (doesn't
matter what it is).  Worst case, O(10**4) times.  

Now let's suppose that the utility curve of a tracker with respect to
some number of developers d is modeled by an unknown function TD(d),
for LOC constant.  And that the joint utility T(LOC, d) is some linear
or multiplicative composite of TL(LOC) and TD(d), eg T(LOC, d) = a *
TL(LOC) + b * TD(d) + c * TL(LOC) * TD(d) for unknown constants a b c.
This is the friendliest possible assumption for you.  In fact the
joint function probably has nonlinear and monotonic-increasing terms
in both variables.

In order for a tracker to be less valuable to Emacs than it is to
Wesnoth, TD(d) would have to drop towards zero so much faster than
LOC**2 that it would swamp a more than two-order-of-magnitude
difference.  in TL(LOC).

To be concrete: I know Emacs has a minimum of about 6 developers just
from watching the list.  Let's say Wesnoth has 12.  That's 2:1.  A 2:1
drop in d would have to swamp a 10:1 rise in LOC.  Not plausible
at all.

(Note one of the things that has changed since Emacs practices
assumed approximately their present form in the early 1990s; back
then, the scaling laws I'm applying were not at all understood.
The germ of them had been present in Brooks's Law c. 1975, but 
it took a lot of work by a lot of people, including Clark and
Baldwin and Ross Anderson and Les Hatton and -- er -- me to
get from vague intuitions to even a qualitative scaling theory.)

> > One of the places a real issue database is most concretely useful is when
> > you're triaging bugs to close on a release.  It is *immensely* helpful
> > in making clear what needs to be done and at what point you are
> > finished doing it.
> 
> In Emacs development, we have problems to even find a release manager,
> let alone someone who will replace Richard as a head maintainer.  So
> having a bug triage system that is significantly better that a flat
> text file such as admin/FOR-RELEASE is not necessarily the first
> priority here.

Perhaps not.  But it certainly couldn't hurt.  And, maybe, if
bug-triage weren't quite so much like having a herd of elephants
stampede over your testicles, a release manager might be just a
*leetle* easier to find?
 
> Emacs is HUGE.  Its immense size is not the only problem: there are
> many parts in it that require experts in specific areas (GUI display,
> networking, Lisp infrastructure, email, multilingual text editing, to
> name just a random few) in order to know what is right and wrong when
> reviewing patches.  Just figuring out how best to organize maintenance
> of such a large package is a daunting task, to say nothing of actually
> implementing such a maintenance scheme (which would mean finding and
> recruiting individuals who could become part of such a team, then
> making a coherent and cooperative team out of them).  

All this is certainly true.

>                                                   It is IMO naive
> at best to think that switching to more collaborative tools would
> somehow magically solve these _real_ problems, or even pave a way for
> their _practical_ solution.

It would be tremendously naive to believe that better collaborative
tools will magically solve these problems. But that's a straw man; I
don't believe it, and you are *certainly* not stupid enough to suppose 
that I do.

But when you exclude the possibility that they might pave the way...
start asking youself how many potential contributors Emacs has lost 
because the project toolkit looks like stone knives and bearskins.

After that unnerving experience I had on 29 December, I can name
names: David Matuszek.  Cyndy Matuszek.  Toren Smith.  Matt Taylor.
Donna Malayeri.  That's five Emacs users and potential contributors
lost right there.  And you know what?  If I had known it was
important, I'm certain I could have walked three steps unto the
Matuszeks' living room and collected five more refuseniks just
from the faces I knew, let alone the strangers.

That's from a single point sample on a single night, and it's more
people than you'll admit to having on your entire dev team.  Wake up;
it's later than you think.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Why Emacs needs a modern bug tracker

[Eli Zaretskii]

> Date: Sat, 5 Jan 2008 13:24:56 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: "Eric S. Raymond" <esr@snark.thyrsus.com>, emacs-devel@gnu.org
> 
> First, the size of a project's bug load is driven by the square of
> LOC.  This is because most bugs are clashes between assumptions mode
> in differing parts of the code.

You are assuming that all parts of the code are being developed, it
seems.  That's not what happens in Emacs, probably due to its age and
the fact that core features are developed/refactored only very seldom,
or not at all.

In any case, unless we lose a huge amount of bugs due to lack of
tracking, the amount of bugs in Emacs is not consistent with the
quadratic curve hypothesis, let alone higher powers.  And the bugs
reported through the various Emacs channels do not suggest that we
leave such a large amount of bugs without fixing, or else we'd have
lots of repeated bug reports.

> > In Emacs development, we have problems to even find a release manager,
> > let alone someone who will replace Richard as a head maintainer.  So
> > having a bug triage system that is significantly better that a flat
> > text file such as admin/FOR-RELEASE is not necessarily the first
> > priority here.
> 
> Perhaps not.  But it certainly couldn't hurt.

``Couldn't hurt'' is not a good argument when deciding where to apply
limited resources.  Like in code optimization, you first try to
identify the hot spots, and then go for those spots first.

But as I said elsewhere, let's have a bug tracker happen, and see
where it gets us.  I have seen enough talking on this issue; if
there's energy left in those who think a bug tracker will make a
difference, let's see it in action and argue later.

> And, maybe, if bug-triage weren't quite so much like having a herd
> of elephants stampede over your testicles, a release manager might
> be just a *leetle* easier to find?

You are certainly not stupid enough to believe I'm talking
theoretically here.  I actually was an Emacs release manager once, and
I don't recall having any special problems managing the bug queue,
certainly not something that could be described as elephants stampede
over my testicles.

What took most of the time during the release is _fixing_ the bugs,
not tracking them.

If your scaling assumptions are true, I don't see how they can be
supported by my own experience of participation in Emacs maintenance.

Re: Why Emacs needs a modern bug tracker

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> You are assuming that all parts of the code are being developed, it
> seems.  That's not what happens in Emacs, probably due to its age and
> the fact that core features are developed/refactored only very seldom,
> or not at all.

OK, fair point.  In that case Emacs will behave, statistically, more
like a project the size of the code's active region.  Not entirely,
you could still have bad interactions with the "dark matter", but...
do you have any idea what the approximate LOC of the active region is?

I might, by straining hard, manage to believe it's smaller than 
Wesnoth.  No way it's going to be smaller than GPSD.
 
> In any case, unless we lose a huge amount of bugs due to lack of
> tracking,

I strongly suspect you do.  This is testable; if it's so, you'll
see a lot more of them as people become aware of the tracker.

> But as I said elsewhere, let's have a bug tracker happen, and see
> where it gets us.  I have seen enough talking on this issue; if
> there's energy left in those who think a bug tracker will make a
> difference, let's see it in action and argue later.

All right.  I'll need administrator permissions on our Savannah site.  
Can you set those?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Why Emacs needs a modern bug tracker

[Eli Zaretskii]

> Date: Sat, 5 Jan 2008 16:48:10 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > You are assuming that all parts of the code are being developed, it
> > seems.  That's not what happens in Emacs, probably due to its age and
> > the fact that core features are developed/refactored only very seldom,
> > or not at all.
> 
> OK, fair point.  In that case Emacs will behave, statistically, more
> like a project the size of the code's active region.  Not entirely,
> you could still have bad interactions with the "dark matter", but...
> do you have any idea what the approximate LOC of the active region is?

Sorry, no.  Someone will have to calculate this based on CVS history.
It's not trivial, because there's lot of development going on in
various Lisp packages, but many of those are fairly isolated from the
rest of Emacs.  So the first step towards estimating this would be to
identify Lisp files that are infrastructure used by many other
packages.  C sources are easier, because most of them are core
functionality, but one still needs to separate new features from
changes to old features (since new features cannot easily break old
code).

> All right.  I'll need administrator permissions on our Savannah site.  
> Can you set those?

If you mean Emacs project administrator privileges, then yes, I can,
but I'll need Richard's approval for that.  If you mean Savannah
administrator privileges, then I cannot do that; you will need to ask
Richard to ask Savannah hackers to do it.

Either way, it's probably a good idea to describe in some detail what
you want to do there, for Richard to consider.

Thanks.

Re: Why Emacs needs a modern bug tracker

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > All right.  I'll need administrator permissions on our Savannah site.  
> > Can you set those?
> 
> If you mean Emacs project administrator privileges, then yes, I can,
> but I'll need Richard's approval for that.  If you mean Savannah
> administrator privileges, then I cannot do that; you will need to ask
> Richard to ask Savannah hackers to do it.
> 
> Either way, it's probably a good idea to describe in some detail what
> you want to do there, for Richard to consider.

I'm not ready to recommend a DVCS yet.  That won't happen until my study
is finished.  If a repo conversion is required at that time, I'll take
responsibility for doing it.

First step: activate the default Savannah issue tracker for the project and 
test it.  Might be that one is good enough; I'll need to check things like 
whether reports can be gated to emacs-bugs, and how much work it takes
to be able to do transactions from within Emacs.

If it's not good enough, two alternatives to look at are tthe Debian tracker
and Bugs Everywhere. It is likely that I would need Savannah admin privs
to put those in.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Why Emacs needs a modern bug tracker

[Nick Roberts]

 > First step: activate the default Savannah issue tracker for the project and 
 > test it.  Might be that one is good enough; I'll need to check things like 
 > whether reports can be gated to emacs-bugs, and how much work it takes
 > to be able to do transactions from within Emacs.

I have proposed this before but without much success:

http://lists.gnu.org/archive/html/emacs-devel/2006-10/msg00560.html

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

Re: Why Emacs needs a modern bug tracker

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
>  > First step: activate the default Savannah issue tracker for the project and 
>  > test it.  Might be that one is good enough; I'll need to check things like 
>  > whether reports can be gated to emacs-bugs, and how much work it takes
>  > to be able to do transactions from within Emacs.
>
> I have proposed this before but without much success:

Perhaps it's improved recently, but the last time I used the savannah
bug tracker it was completely awful, and seemed to have no email
support other than sending bug status changes and the like.

-Miles

-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: Why Emacs needs a modern bug tracker

[Nick Roberts]

 > Perhaps it's improved recently, but the last time I used the savannah
 > bug tracker it was completely awful, and seemed to have no email
 > support other than sending bug status changes and the like.

Yes it looks like Bugzilla is far superior.  I know that this has also been
suggested before, and I'm trying not to go round in circles, but I notice now
that GCC use their mailing list gcc-bugs for their Bugzilla bug-tracking
system.  If we set Emacs up similarly, then presumably Richard (and others)
could use e-mail as before, while those that want to could submit bug reports
through Bugzilla.

Perhaps Andreas Schwab (or anyone else who is familiar with gcc-bugs) could
comment on how this works for GCC?

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

Re: Why Emacs needs a modern bug tracker

[Andreas Schwab]

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

> Perhaps Andreas Schwab (or anyone else who is familiar with gcc-bugs) could
> comment on how this works for GCC?

GCC bugzilla is maintained by Daniel Berlin.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Why Emacs needs a modern bug tracker

[Nick Roberts]

 > > Perhaps Andreas Schwab (or anyone else who is familiar with gcc-bugs) could
 > > comment on how this works for GCC?
 > 
 > GCC bugzilla is maintained by Daniel Berlin.

It looks like an answer but probably to a different question.  I mean't things
like:

Can someone follow/participate in discussion of all bug reports from e-mail
only by being subscribed to gcc-bugs?

Do all bug reports in gcc-bugs come from Bugzilla?  What happens if someone
tries to submit a bug report directly to gcc-bugs without using Bugzilla?

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

Re: Why Emacs needs a modern bug tracker

[Andreas Schwab]

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

> Can someone follow/participate in discussion of all bug reports from e-mail
> only by being subscribed to gcc-bugs?

Yes.

> Do all bug reports in gcc-bugs come from Bugzilla?

gcc-bugs is a normal, open mailing list.  From time to time it receives
spam and other non-bugzilla mails.

> What happens if someone tries to submit a bug report directly to
> gcc-bugs without using Bugzilla?

AFAIK only mail sent to gcc-bugzilla are seen by bugzilla, and all mails
sent out by bugzilla have a reply-to header redirecting there.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Why Emacs needs a modern bug tracker

[David Kastrup]

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

>  > Perhaps it's improved recently, but the last time I used the savannah
>  > bug tracker it was completely awful, and seemed to have no email
>  > support other than sending bug status changes and the like.
>
> Yes it looks like Bugzilla is far superior.  I know that this has also been
> suggested before, and I'm trying not to go round in circles, but I notice now
> that GCC use their mailing list gcc-bugs for their Bugzilla bug-tracking
> system.  If we set Emacs up similarly, then presumably Richard (and others)
> could use e-mail as before, while those that want to could submit bug reports
> through Bugzilla.

If Savannah's bug report system is completely awful and Bugzilla is far
superior, then this would seem like something that would warrant
changing Savannah policies or options instead of just special-casing
Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Why Emacs needs a modern bug tracker

[Eric S. Raymond]

David Kastrup <dak@gnu.org>:
> If Savannah's bug report system is completely awful and Bugzilla is far
> superior, then this would seem like something that would warrant
> changing Savannah policies or options instead of just special-casing
> Emacs.

Agreed.  That would have the advantage of lowering the Savannah admins'
maintainance load after the transition.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

    Agreed.  That would have the advantage of lowering the Savannah admins'
    maintainance load after the transition.

If Bugzilla is superior, it would provide an advantage to the projects
hosted on Savannah.  But how would installing Bugzilla on Savannah
reduce the Savannah admins' maintainance load?  I would like to
understand this, because maybe it will be an argument I should
present.

Re: Why Emacs needs a modern bug tracker

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
>     Agreed.  That would have the advantage of lowering the Savannah admins'
>     maintainance load after the transition.
> 
> If Bugzilla is superior, it would provide an advantage to the projects
> hosted on Savannah.  But how would installing Bugzilla on Savannah
> reduce the Savannah admins' maintainance load?  I would like to
> understand this, because maybe it will be an argument I should
> present.

Nothing complicated.  I just meant that if the Savannah admins
switched to Bugzilla globally rather than locally for Emacs, they
wouldn't have to administer two different trackers down the road.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

    Nothing complicated.  I just meant that if the Savannah admins
    switched to Bugzilla globally rather than locally for Emacs, they
    wouldn't have to administer two different trackers down the road.

I see.  Thanks.

Re: Why Emacs needs a modern bug tracker

[Bill Wohler]

David Kastrup <dak@gnu.org> writes:

> Nick Roberts <nickrob@snap.net.nz> writes:
>
>>  > Perhaps it's improved recently, but the last time I used the savannah
>>  > bug tracker it was completely awful, and seemed to have no email
>>  > support other than sending bug status changes and the like.
>>
>> Yes it looks like Bugzilla is far superior.  I know that this has also been
>> suggested before, and I'm trying not to go round in circles, but I notice now
>> that GCC use their mailing list gcc-bugs for their Bugzilla bug-tracking
>> system.  If we set Emacs up similarly, then presumably Richard (and others)
>> could use e-mail as before, while those that want to could submit bug reports
>> through Bugzilla.
>
> If Savannah's bug report system is completely awful and Bugzilla is far
> superior, then this would seem like something that would warrant
> changing Savannah policies or options instead of just special-casing
> Emacs.

That's true, but I don't think Bugzilla is superior enough to warrant
that. Some might argue it isn't even better.

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

Re: Why Emacs needs a modern bug tracker

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: esr@thyrsus.com,  esr@snark.thyrsus.com,  Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 06 Jan 2008 11:08:06 +0900
> 
> Perhaps it's improved recently, but the last time I used the savannah
> bug tracker it was completely awful, and seemed to have no email
> support other than sending bug status changes and the like.

I don't know about ``awful'' (you didn't say what was awful about it),
but at least as far as email gateway, the GNU Make project has it set
up and running: every bug report gets gatewayed into a mailing list,
and so does any comment filed with a bug report.  My only gripe is
that attached files (patches) do not show in the emailed reflections
except as URLs, so one need to go to a Web browser to see them.

Re: Why Emacs needs a modern bug tracker

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> Perhaps it's improved recently, but the last time I used the savannah
>> bug tracker it was completely awful, and seemed to have no email
>> support other than sending bug status changes and the like.
>
> I don't know about ``awful'' (you didn't say what was awful about it),
> but at least as far as email gateway, the GNU Make project has it set
> up and running: every bug report gets gatewayed into a mailing list,
> and so does any comment filed with a bug report. 

Useful email support means supporing both submissions, modifications,
and queries via email.

[Supposedly recent versions of bugzilla support such, but I haven't used it.]

-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: Why Emacs needs a modern bug tracker

[Yavor Doganov]

Miles Bader wrote:
> 
> Useful email support means supporing both submissions,
> modifications, and queries via email.

Exactly.  This is not supported by Savane, so this fact automatically
rules out Savannah as a bug tracker for Emacs.

I wonder why nobody mentioned GNATS, the GNU Bug Tracking System?
From the description:

,---- http://www.gnu.org/software/gnats/ ----
| Thanks to its architecture, GNATS is not bound to a single
| user interface – it can be used via command line, e-mail, Emacs, or a
| network daemon, usually used with a Web interface.  Together with the
| fact that all GNATS databases and configuration can be stored in plain
| text files, it allows easy use and provides good flexibility.
| Basically, if the GNATS tools do not provide everything you need, you
| can add your own additional utilities using standard GNU tools.
`----

There was a running instance once upon a time at bugs.gnu.org, but I
don't know what happened.  AFAIK the FreeBSD folks use it as a tracker
for the whole distribution, so it can't be that bad.


I guess that the most reasonable course of action is:  Those that
promote the idea of a bug tracking system make a research of all
available solutions (debbugs, Trac with the email support plugin,
GNATS, the GCC Bugzilla, etc.) and prepare a comparison list with
advantages/disatvantages, so that Emacs developers can discuss based
on it and eventually decide which BTS is the most appropriate one.

Re: Why Emacs needs a modern bug tracker

[Giorgos Keramidas]

On 2008-01-07 16:40, Yavor Doganov <yavor@gnu.org> wrote:
> Miles Bader wrote:
> > Useful email support means supporing both submissions,
> > modifications, and queries via email.
>
> Exactly.  This is not supported by Savane, so this fact automatically
> rules out Savannah as a bug tracker for Emacs.
>
> I wonder why nobody mentioned GNATS, the GNU Bug Tracking System?
> From the description:
>
> ,---- http://www.gnu.org/software/gnats/ ----
> | Thanks to its architecture, GNATS is not bound to a single
> | user interface ??? it can be used via command line, e-mail, Emacs, or a
> | network daemon, usually used with a Web interface.  Together with the
> | fact that all GNATS databases and configuration can be stored in plain
> | text files, it allows easy use and provides good flexibility.
> | Basically, if the GNATS tools do not provide everything you need, you
> | can add your own additional utilities using standard GNU tools.
> `----
>
> There was a running instance once upon a time at bugs.gnu.org, but I
> don't know what happened.  AFAIK the FreeBSD folks use it as a tracker
> for the whole distribution, so it can't be that bad.

As one of the people who used to be gnats-admin for FreeBSD, I can tell
you that it _is_ bad in some ways.

FreeBSD has a very active Gnats admin, Mark Linimon, who spends a *lot*
of time working with the members of the `bugmeister' team to keep things
going.  I am not sure if I could ever keep up with the work Gnats needs
to keep working smoothly, but Mark has been doing a fantastically
marvellous job for several years now.

Before using Gnats for Emacs, I think you should ask Mark about his
experience with Gnats the past few years.  I'm sure he has alot of
useful contributions to make regarding the goodness or badness of Gnats.

I have added Mark to the Cc: list, in case he wants to offer any help
regarding a choice pro or against Gnats.

Re: Why Emacs needs a modern bug tracker

[Mark Linimon]

On Thu, Jan 10, 2008 at 06:23:40AM +0200, Giorgos Keramidas wrote:
> FreeBSD has a very active Gnats admin, Mark Linimon, who spends a *lot*
> of time working with the members of the `bugmeister' team to keep things
> going.

To be fair, most of the time I spend on maintainance is spent on what's
inside the database rather than maintaining the thing itself.  We do have
a number of scripts (auto-assigners, auto-reminders, etc.) that we have
layered on top of it.  These do much of the maintainance work.

Having said that, opinions on GNATS within the FreeBSD community are
sharply divided.  Like CVS, it is a dull stone axe, whose appeal is
that people are familiar with the paradigm, and all the rough edges are
well-known.  Without the auto-assigner, I think it would already have
collapsed under its own weight -- and we only have the auto-assigner
for ports.  I will accept the argument that it already _has_ for src.

The problem with replacing it is that IMHO we have to understand how
people really want to interact with a tool before implementing a new
one.  This is much more a 'define the problem' area rather than 'pick
an existing thing and install it'.  (There are those inside FreeBSD who
have been advocating that e.g. Bugzilla or Trac will solve all our
problems; my view is that until we model our desired workflow, we may
just implement something else that does _also_ not meet our needs).

I don't think I would recommend GNATS for a new installation, unless
the number of bugs is expected to be small and the number of developers
limited.  Its search and classification capabilities are simply not up
to modern standards.

There is also the problem that the backing store is a set of flat-files
rather than a true database.  This means that it's difficult to add new
queries.  (My own software at portsmon.freebsd.org simply grabs the
contents of the database and uses some magic to convert much of its
metadata into SQL, so I can integrate it with our ports build cluster
output).

If you want to look at what we've added to the GNATS web interface, play
with http://www.freebsd.org/cgi/query-pr-summary.cgi?query.  It's more
usable than the default that came with it; I consider the work there
necessary but insufficient.

Final note: in my last full-time job we evaluated a number of problem
report trackers (both commercial and open-source) and concluded that
they *all* stink.  Most seem to have been written by some guy like me
who is more interested in laying out fields in a database and designing
a pretty UI, rather than going through the hard work of designing use-
cases, proposing strawmen, and going through a period of working with
all the interested parties to get a buy-in.  But even though that's my
default mode, I know it won't produce the desired result in this case.
(I'm intending to work on that this year).

To summarize, implementing a bug tracker is more a peopleware problem
than a technical problem.  As such, it is much harder to get a handle on.

mcl

Re: Why Emacs needs a modern bug tracker

[Bill Wohler]

Yavor Doganov <yavor@gnu.org> writes:

> I guess that the most reasonable course of action is:  Those that
> promote the idea of a bug tracking system make a research of all
> available solutions (debbugs, Trac with the email support plugin,
> GNATS, the GCC Bugzilla, etc.) and prepare a comparison list with
> advantages/disatvantages, so that Emacs developers can discuss based
> on it and eventually decide which BTS is the most appropriate one.

  http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems

Richard Stallman <rms@gnu.org> writes:

> If we are to use a bug tracker, it must allow people to do everything
> thru email if they wish to, and must make that mode convenient.

<Messages regarding debbugs omitted>

> It sounds like a plausible candidate.  Whether it is really ok in practice
> depends on the details of what using it is like.

I think you'd really like debbugs (Debian BTS), Richard, for the same
reasons I love it (as a user). It's completely driven via email and
has few knobs and whistles.

Documentation about debbugs and a simple reporting form can be found
at:

  http://www.us.debian.org/Bugs/

As a user, I submit bugs from Emacs using `M-x debian-bug' (written by
Peter Galbraith, a Debian maintainer and a Emacs committer as well).
Like report-emacs-bug, it fills in the necessary pseudo-headers and
environment information. Unlike report-emacs-bug, it also provides
completion for the package or pseudo-package (which would also be
useful within Emacs) and menu items to manipulate the pseudo-headers
(Severity, Tags, etc.) and to view other bugs for the same package.
Instead of submitting a new bug, I might see that a bug has already
been posted and can add new information to it, simply by replying to
the message.

At that point the dialog is completely performed in email, and the
best part, I get email when the bug is closed so I'll know when to
look for the fix.

The metadata for the bug are controlled by the developer with
pseudo-headers in an email. Peter, are there other Emacs tools to
manipulate control messages?

> That sounds ok, so far.  Can you show me what a couple of these
> messages look like?

A list of all bugs in the Emacs package:

  http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=emacs22;dist=unstable

A bug report that goes from start to finish and shows pseudo-headers.

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456235

Martin Geisler <mgeisler@mgeisler.net> writes:

> People how know the bug tracker better can probably also comment on
> whether or not it can be used outside Debian at all, or if it is too
> heavily tied to the Debian infrastructure to be useful elsewhere.

It seems so since it appears as a package (the tarball is available
from the following link):

  http://packages.debian.org/lenny/debbugs

Peter, can you speak to that?

p.s. This thread can be referenced via

  http://thread.gmane.org/gmane.emacs.devel/86069/

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

Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

Bill Wohler <wohler@newt.com> writes:

[snip]

> I think you'd really like debbugs (Debian BTS), Richard, for the same
> reasons I love it (as a user). It's completely driven via email and
> has few knobs and whistles.
>
> Documentation about debbugs and a simple reporting form can be found
> at:
>
>   http://www.us.debian.org/Bugs/

At first it looks nice.

But has it support for submitting bugs using web forms?

OTOH, I think there is something wrong with a system that has 9
screenfulls of instructions for just reporting a bug.

[snip]

-- 
Oscar

Re: Why Emacs needs a modern bug tracker

[Ralf Angeli]

* Óscar Fuentes (2008-01-11) writes:

> Bill Wohler <wohler@newt.com> writes:
>
>>   http://www.us.debian.org/Bugs/
>
> At first it looks nice.
>
> But has it support for submitting bugs using web forms?
>
> OTOH, I think there is something wrong with a system that has 9
> screenfulls of instructions for just reporting a bug.

`reportbug' takes you through the process quite nicely.

-- 
Ralf

Re: Why Emacs needs a modern bug tracker

[Nick Roberts]

 > > I think you'd really like debbugs (Debian BTS), Richard, for the same
 > > reasons I love it (as a user). It's completely driven via email and
 > > has few knobs and whistles.
 > >
 > > Documentation about debbugs and a simple reporting form can be found
 > > at:
 > >
 > >   http://www.us.debian.org/Bugs/
 > 
 > At first it looks nice.
 > 
 > But has it support for submitting bugs using web forms?

Good point.  We can find a bug tracking system that suits RMS's needs but, at
the end of the day, it's not worth anything if it doesn't suit those of the
user.  I suspect most, especially younger users, would prefer web forms to
e-mail.

 > OTOH, I think there is something wrong with a system that has 9
 > screenfulls of instructions for just reporting a bug.

That also might deter users from submitting bugs, if much of the detail
is for submission only.

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

Re: Why Emacs needs a modern bug tracker

[David Kastrup]

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

>  > > I think you'd really like debbugs (Debian BTS), Richard, for the same
>  > > reasons I love it (as a user). It's completely driven via email and
>  > > has few knobs and whistles.
>  > >
>  > > Documentation about debbugs and a simple reporting form can be found
>  > > at:
>  > >
>  > >   http://www.us.debian.org/Bugs/
>  > 
>  > At first it looks nice.
>  > 
>  > But has it support for submitting bugs using web forms?
>
> Good point.  We can find a bug tracking system that suits RMS's needs
> but, at the end of the day, it's not worth anything if it doesn't suit
> those of the user.  I suspect most, especially younger users, would
> prefer web forms to e-mail.

Please don't act on suspicions about "dumb/younger/whatever users"
alone.  While it is certainly not uncommon to suspect the rest of the
world to be composed of strange people whose behaviors and preferences
one can't really comprehend, there would actually be very little
motivation for those to play around with Emacs in the first place.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Why Emacs needs a modern bug tracker

[Evans Winner]

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

    But has it support for submitting bugs using web forms?
 
FWIW, it's not, in principle, difficult to implement a cgi program to
turn a web form submission into a formatted email.  (Doing so securely
may or may not be more hassle.)

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

debbugs looks plausible, but what I would really like
is for someone to try using the various possible bug trackers,
limiting himself to email, and report on how well each one works
in that mode.

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

    > But as I said elsewhere, let's have a bug tracker happen, and see
    > where it gets us.  I have seen enough talking on this issue; if
    > there's energy left in those who think a bug tracker will make a
    > difference, let's see it in action and argue later.

    All right.  I'll need administrator permissions on our Savannah site.  
    Can you set those?

Hold your horses!  I'm now willing to consider use of a bug tracker,
but that leaves the question of WHICH ONE, and checking that it is
actually ok to use.

    > First step: activate the default Savannah issue tracker for the
    > project and test it.  Might be that one is good enough; I'll
    > need to check things like whether reports can be gated to
    > emacs-bugs, and how much work it takes to be able to do
    > transactions from within Emacs.

Miles says that one was no good, when he tried it.  On the other hand,
Eli says now it works ok for GNU Make:

    I don't know about ``awful'' (you didn't say what was awful about it),
    but at least as far as email gateway, the GNU Make project has it set
    up and running: every bug report gets gatewayed into a mailing list,
    and so does any comment filed with a bug report.

Can you issue commands by email too?

Re: Why Emacs needs a modern bug tracker

[Martin Geisler]

[-- Attachment #1.1: Type: text/plain, Size: 1501 bytes --]

Richard Stallman <rms@gnu.org> writes:

> [...]
>
> Can you issue commands by email too?

This is not about the Savannah bug tracker, but as mentioned briefly
elsewhere in this thread the Debian bug tracker can be controlled by
email. I'm a Debian user and have submitted a couple of bugs that way.

Bugs can fully controlled (opened, closed, merged, etc.) using email.
The control messages look like this (I picked bug #100000 as a random
example):

  reassign 100000 xlibs
  merge 100000 96562
  retitle 100000 xlibs: [xkb] Another alt keys not -> meta keysyms report
  thanks

These commands are included in the email body and sent to
control@bugs.debian.org. All comments and changes to a bug is available
online

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=100000

and the submitter and package maintainers are sent email copies of the
changes.

I'm sure there are people here who can describe the Debian bug tracker
much better than I can, but I hope the above gives the idea. Much more
information can be found here:

  http://www.debian.org/Bugs/

People how know the bug tracker better can probably also comment on
whether or not it can be used outside Debian at all, or if it is too
heavily tied to the Debian infrastructure to be useful elsewhere.

-- 
Martin Geisler

      Do your secure multi-party computations (SMPC) with VIFF,
              the Virtual Ideal Functionality Framework.
                     Download at http://viff.dk/

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

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Why Emacs needs a modern bug tracker

[Richard Stallman]

      reassign 100000 xlibs
      merge 100000 96562
      retitle 100000 xlibs: [xkb] Another alt keys not -> meta keysyms report
      thanks

    These commands are included in the email body and sent to
    control@bugs.debian.org. All comments and changes to a bug is available
    online

That looks usable, at first glance.

Re: Why Emacs needs a modern bug tracker

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, esr@snark.thyrsus.com, emacs-devel@gnu.org
> Date: Sun, 06 Jan 2008 13:09:43 -0500
> 
>     I don't know about ``awful'' (you didn't say what was awful about it),
>     but at least as far as email gateway, the GNU Make project has it set
>     up and running: every bug report gets gatewayed into a mailing list,
>     and so does any comment filed with a bug report.
> 
> Can you issue commands by email too?

I don't think so, but Savannah hackers should know better.

Re: Why Emacs needs a modern bug tracker

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> Hold your horses!  I'm now willing to consider use of a bug tracker,
> but that leaves the question of WHICH ONE, and checking that it is
> actually ok to use.

I unserstand this.  I said in previous mail that we need to evaluate
the Savannah tracker, then look at Bugs Everywhere and the Debian bug tracker
if that's not good enough.
 
> Can you issue commands by email too?

I don't know.  But I'm willing to do the work to find out.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>