Bug Database?

Bug Database?

[Nick Roberts]

As a point of reference GDB has 1218 open bugs in its database and still gets
released roughly on a six monthly cycle.  Bugs are generally fixed by those who
find them most inconvenient.  I'm quite sure if they all had to be fixed first
it would never get released.  I use Emacs every day and I must say I've not
encountered any of the bugs currently in FOR-RELEASE.  How about Emacs using a
bug database?  GDB uses GNATS, but it could be Bugzilla.  I think the important
thing is that reported bugs don't get lost between the cracks, not that every
bug is fixed before the release.

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

Re: Bug Database?

[David Reitter]

On 17 Oct 2006, at 22:49, Nick Roberts wrote:

> I'm quite sure if they all had to be fixed first
> it would never get released.  I use Emacs every day and I must say  
> I've not
> encountered any of the bugs currently in FOR-RELEASE.

For about 18 months, I've been releasing a downstream project with  
binary builds of  patched and augmented GNU Emacs CVS checkouts  
(http://aquamacs.org). We have around 3,500 different users in any  
given week and more than 10,000 application starts a day. We're doing  
monthly or bi-monthly releases. The users have proven to be a useful  
test community. Over time, we have seen a lot of bug reports from  
users, some of which concerning bugs due to the use of functions in  
Emacs that wouldn't otherwise be used in a straight CVS build. I've  
generated or checked and passed on about 150 bug reports as a result,  
as my e-mail archive tells me. (Almost all of them were quickly fixed  
by maintainers!)

It appears that the bug reports I am receiving (which actually  
concern issues in the Emacs core) have been getting a lot more scarce  
over the past couple of months, even though our user base has been  
growing. That's a good sign.

That said, good quality is what people are expecting from a project  
that doesn't release very often...

Re: Bug Database?

[Chong Yidong]

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

>  I think the important thing is that reported bugs don't get lost
> between the cracks, not that every bug is fixed before the release.

We've been through this before.  Everyone agrees with your statement
except RMS.

Re: Bug Database?

[Nick Roberts]

 > >  I think the important thing is that reported bugs don't get lost
 > > between the cracks, not that every bug is fixed before the release.
 > 
 > We've been through this before.  Everyone agrees with your statement
 > except RMS.

Yes, but I'm also suggesting use of a bug database to ensure that reported bugs
don't get lost.  That has also come up before and was considered unnecessary,
but at that time reported bugs were only recorded in the archives.


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

Re: Bug Database?

[Jan Djärv]

Nick Roberts skrev:
>  > >  I think the important thing is that reported bugs don't get lost
>  > > between the cracks, not that every bug is fixed before the release.
>  > 
>  > We've been through this before.  Everyone agrees with your statement
>  > except RMS.
> 
> Yes, but I'm also suggesting use of a bug database to ensure that reported bugs
> don't get lost.  That has also come up before and was considered unnecessary,
> but at that time reported bugs were only recorded in the archives.
> 

FWIW I think such a database (Bugzilla?) would help.  Right now I have bugs 
that shall be fixed to the release (just found out I forgot to do the UTF-8 in 
selection thingy), bugs/features that are for after the release, and bugs that 
are hard to reproduce, but are on some kind of watch-list.

A database would be a good place to clearly mark the type of bug/feature 
request, and the planned release.  A more structured FOR-RELEASE, but not just 
for the next release.  It would hopefully be easier to search and browse than 
my inbox + Emacs mailing lists.

	Jan D.

Re: Bug Database?

[Richard Stallman]

    Yes, but I'm also suggesting use of a bug database to ensure that reported bugs
    don't get lost.  That has also come up before and was considered unnecessary,
    but at that time reported bugs were only recorded in the archives.

It would be useful to run a bug tracker, but I have never done so, and
I don't know what work for us is required.  Do we transfer the bugs
into the tracker by hand?  If so, who wants to do that?

Re: Bug Database?

[Richard Stallman]

    As a point of reference GDB has 1218 open bugs in its database and still gets
    released roughly on a six monthly cycle.

I suspect it means there is insufficient priority to fixing GDB bugs.

Re: Bug Database?

[Juanma Barranquero]

On 10/18/06, Richard Stallman <rms@gnu.org> wrote:

> It would be useful to run a bug tracker, but I have never done so, and
> I don't know what work for us is required.

There are quite a few issue tracking systems easy to install and easy
to manage (RT, for example). CVSTrac also includes a wiki, which is
nice.

> Do we transfer the bugs into the tracker by hand?

Yes, if you want to assign difficulty/priority values to them...

> If so, who wants to do that?

I don't think just one person should shoulder that, unless we're
talking of a few dozens bugs. No need, either.

-- 
                    /L/e/k/t/u

Re: Bug Database?

[Nick Roberts]

 >     Yes, but I'm also suggesting use of a bug database to ensure that
 >     reported bugs don't get lost.  That has also come up before and was
 >     considered unnecessary, but at that time reported bugs were only
 >     recorded in the archives.
 > 
 > It would be useful to run a bug tracker, but I have never done so, and
 > I don't know what work for us is required.  

It could be as easy as turning on the bug tracker for Emacs in Savannah.  I
don't know how good/bad it is but it must be an improvement on FOR-RELEASE.

At the other end of the spectrum someone could presumably set up Bugzilla for
the whole of the GNU Project/All Savannah projects.  Although that might
conflict with projects that have already turned their tracker on, I would
guess you would end up with a superior system.  I suggest asking your
sysadmin people.

 >                                             Do we transfer the bugs
 > into the tracker by hand?  If so, who wants to do that?

There are only half a dozen or so that need to be done by us.  I guess we
would direct people to enter future ones into the database themselves.

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

Re: Bug Database?

[Nick Roberts]

 >     As a point of reference GDB has 1218 open bugs in its database and still
 >     gets released roughly on a six monthly cycle.
 > 
 > I suspect it means there is insufficient priority to fixing GDB bugs.

It depends how you measure things.  They have more people using a recent
version of GDB and more people fixing bugs.  There's a clear message: if you
want it fixed for the next version then you may have to fix it yourself.

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

Re: Bug Database?

[joakim]

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

>  >     Yes, but I'm also suggesting use of a bug database to ensure that
>  >     reported bugs don't get lost.  That has also come up before and was
>  >     considered unnecessary, but at that time reported bugs were only
>  >     recorded in the archives.
>  > 
>  > It would be useful to run a bug tracker, but I have never done so, and
>  > I don't know what work for us is required.  
>
> It could be as easy as turning on the bug tracker for Emacs in Savannah.  I
> don't know how good/bad it is but it must be an improvement on FOR-RELEASE.

We use the Savannah bugtracker for MLDonkey. Its quite acceptable,
IMHO. Sure, there are better trackers(like "Trac") but why overdo it?

(One problem is that I cant seem to login to Savannah with emacs-w3m
anymore. I reported this somewhere, but dont quite remember the status
of it.)

Punching in a dozen of bugs from a file is doable and I could do it.

> At the other end of the spectrum someone could presumably set up Bugzilla for
> the whole of the GNU Project/All Savannah projects.  Although that might
> conflict with projects that have already turned their tracker on, I would
> guess you would end up with a superior system.  I suggest asking your
> sysadmin people.
>
>  >                                             Do we transfer the bugs
>  > into the tracker by hand?  If so, who wants to do that?
>
> There are only half a dozen or so that need to be done by us.  I guess we
> would direct people to enter future ones into the database themselves.
>
> -- 
> Nick                                           http://www.inet.net.nz/~nickrob

-- 
Joakim Verona

Emacs-based web browser (was Re: Bug Database?)

[Magnus Henoch]

joakim@verona.se writes:

> (One problem is that I cant seem to login to Savannah with emacs-w3m
> anymore. I reported this somewhere, but dont quite remember the status
> of it.)

I invite you to try the CVS version of Emacs/W3 (not to be confused
with emacs-w3m).  Bugs are being fixed.

Magnus

Re: Emacs-based web browser

[Stefan Monnier]

>> (One problem is that I cant seem to login to Savannah with emacs-w3m
>> anymore. I reported this somewhere, but dont quite remember the status
>> of it.)

> I invite you to try the CVS version of Emacs/W3 (not to be confused
> with emacs-w3m).  Bugs are being fixed.

Cool ;-)


        Stefan

Re: Emacs-based web browser

[Lennart Borgman]

Stefan Monnier wrote:
>>> (One problem is that I cant seem to login to Savannah with emacs-w3m
>>> anymore. I reported this somewhere, but dont quite remember the status
>>> of it.)
>>>       
>
>   
>> I invite you to try the CVS version of Emacs/W3 (not to be confused
>> with emacs-w3m).  Bugs are being fixed.
>>     
>
> Cool ;-)
>
>
>         Stefan
>   

And how do you know, where did you find it? ;-)

Re: Bug Database?

[Richard Stallman]

    A database would be a good place to clearly mark the type of bug/feature 
    request, and the planned release.  A more structured FOR-RELEASE, but not just 
    for the next release.  It would hopefully be easier to search and browse than 
    my inbox + Emacs mailing lists.

One advantage of FOR-RELEASE is that it is a text file,
and can be read without a net connection.

Can we arrange for a bug tracker to provide a list of important bugs
as a text file?

Re: Emacs-based web browser

[Magnus Henoch]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> And how do you know, where did you find it? ;-)

I just updated the web page at http://www.gnu.org/software/w3/ to
reflect reality.

Magnus

Re: Bug Database?

[Richard Stallman]

    > If so, who wants to do that?

    I don't think just one person should shoulder that, unless we're
    talking of a few dozens bugs. No need, either.

This is a misunderstanding; I did not say it should be one person.

If we are to run a bug tracker, we first need to work out a plan for
entering bugs reported by email into the data base.  We need to find a
person or persons who will do the work.

Re: Bug Database?

[Richard Stallman]

    There are only half a dozen or so that need to be done by us.  I guess we
    would direct people to enter future ones into the database themselves.

We seem to be miscommunicating.

People will continue reporting bugs to bug-gnu-emacs and to
emacs-pretest-bugs.  How will we transfer those bug reports
into the bug tracking system?

Re: Bug Database?

[Richard Stallman]

     > I suspect it means there is insufficient priority to fixing GDB bugs.

    It depends how you measure things.  They have more people using a recent
    version of GDB and more people fixing bugs.

I don't understand what you mean by that.

Re: Bug Database?

[Frank Schmitt]

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

>  >     As a point of reference GDB has 1218 open bugs in its database and still
>  >     gets released roughly on a six monthly cycle.
>  > 
>  > I suspect it means there is insufficient priority to fixing GDB bugs.
>
> It depends how you measure things.  They have more people using a recent
> version of GDB and more people fixing bugs.  There's a clear message: if you
> want it fixed for the next version then you may have to fix it yourself.

Which results in the fact that gdb is since years completely unusable
for C++ programs relying on templated functions (so basically all C++
programs which aren't just pimped C). 

So most C++ developers I know have switched to the "free as in free beer
but not free as in free software" debugger from Sun Studio which in
contrast to gdb works really well.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Bug Database?

[Juanma Barranquero]

On 10/19/06, Richard Stallman <rms@gnu.org> wrote:

> This is a misunderstanding; I did not say it should be one person.

You're right. I misread "who" as singular (you know, "quien/quienes"
is number-inflected in Spanish :)

> We need to find a person or persons who will do the work.

I'd volunteer to be one (just not The Only One :)

-- 
                    /L/e/k/t/u

Re: Bug Database?

[Nick Roberts]

 > People will continue reporting bugs to bug-gnu-emacs and to
 > emacs-pretest-bugs.  How will we transfer those bug reports
 > into the bug tracking system?

Only significant bugs that can't be immediately fixed need to be entered,
although it wouldn't matter if others were too as they can easily be closed.

You could just see it as an additional tool.  As a start why not just ask the
Savannah Hackers to turn on the bug tracker for Emacs?  Then people who want to
use it could file bugs there, and you could keep your own record in
FOR-RELEASE.

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

Re: Bug Database?

[Jason Rumney]

Richard Stallman wrote:
> If we are to run a bug tracker, we first need to work out a plan for
> entering bugs reported by email into the data base.  We need to find a
> person or persons who will do the work.
>   
It seems like the sort of job that could easily be automated by a 
script. In fact, my preference would be to have the script be the only 
recipient of the emacs-pretest-bug and bug-emacs mail aliases, and to 
create the entry in the bug database, then add the bug id into the email 
before forwarding it to the mailing list subscribers. Things like 
prioritizing and categorizing would still have to be done by hand, but 
at least there is a guarantee that all bugs make it into the database.

Spam might be a problem with that approach, so perhaps only 
automatically add bugs that are in the format created by 
report-emacs-bug, and forward incorrectly formatted emails directly to 
the list for manual addition.

Re: Bug Database?

[David Kastrup]

Frank Schmitt <ich@frank-schmitt.net> writes:

> Nick Roberts <nickrob@snap.net.nz> writes:
>
>>  >     As a point of reference GDB has 1218 open bugs in its
>>  >     database and still gets released roughly on a six monthly
>>  >     cycle.
>>  > 
>>  > I suspect it means there is insufficient priority to fixing GDB bugs.
>>
>> It depends how you measure things.  They have more people using a
>> recent version of GDB and more people fixing bugs.  There's a clear
>> message: if you want it fixed for the next version then you may
>> have to fix it yourself.
>
> Which results in the fact that gdb is since years completely unusable
> for C++ programs relying on templated functions (so basically all C++
> programs which aren't just pimped C). 

One could argue that C++ was more in need of fixing than GDB...
Unfortunately, C++ got standardized before we could standardize GDB.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Bug Database?

[Nick Roberts]

 > > It depends how you measure things.  They have more people using a recent
 > > version of GDB and more people fixing bugs.  There's a clear message: if
 > > you want it fixed for the next version then you may have to fix it
 > > yourself.
 > 
 > Which results in the fact that gdb is since years completely unusable
 > for C++ programs relying on templated functions (so basically all C++
 > programs which aren't just pimped C). 

We're moving a bit off-topic but I think refusing to release it until
it worked well for templated functions etc would just mean it didn't get
released at all.

 > So most C++ developers I know have switched to the "free as in free beer
 > but not free as in free software" debugger from Sun Studio which in
 > contrast to gdb works really well.

People can choose not to fix GDB, it's a voluntary project.

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

Re: Bug Database?

[Frank Schmitt]

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

>  > So most C++ developers I know have switched to the "free as in free beer
>  > but not free as in free software" debugger from Sun Studio which in
>  > contrast to gdb works really well.
>
> People can choose not to fix GDB, it's a voluntary project.

First for those who have no idea about what we are talking about: In C++
you can write something like

-----------------------------------------------------------------------------
template <typename imgtype1, typename imgtype2>
void doSomething(imgtype1* img1, imgtype2* img2){
  //do something with image img1 and image img2 which can both be either
  //8 or 16 bits per pixel
}

int main(){
  unsigned char* image1 = getRawImageData1();
  int bpp1 = getBitsPerPixel1();
  unsigned char* image2 = getRawImageData2():
  int bpp2 = getBitsPerPixel2();
  if (bpp1==8 && bpp2==8)
     doSomething<unsigned char, unsigned char>(image1, image2);
  if (bpp1==8 && bpp2==16)
     doSomething<unsigned char, unsigned short>(image1, (unsigned short*)image2);
  if (bpp1==16 && bpp2==8)
     doSomething<unsigned short, unsigned char>((unsigned short*)image1, image2);
  if (bpp1==16 && bpp2==16)
     doSomething<unsigned short, unsigned short>((unsigned short*)image1, (unsigned short*)image2);
}
-----------------------------------------------------------------------------

If you compile this, four instances of the function doSomething are
generated, in each imgtype1 and imgtype2 is substituted with a real data
type. If you now start the program in gdb and say "break doSomething",
the breakpoint will always be set at the first instance of the function
which gdb finds. If this isn't the instance your program is just using,
you can't debug the function. (Ok, there are some tricks, but even if
you managed to set the breakpoint correctly there's still reakage in
e.g. "until".)

So basically what had to be done is: If you make the lookup between line
in source code and offset in object code, look if you are in a templated
function, if yes search for all matching offsets in object code instead
of only the first one. I looked at the code and while I wasn't able to
do the fix myself, I think for someone who knows gdb's internal, the fix
wouldn't be much work.

If gdb had a leader who said "we don't ship broken code", gdb developers
would be at annoyed because their favorite new feature of which they are
proud and fond isn't released to the public and would eventually sit
down and fix it, just as it happens in Emacs.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Bug Database?

[Juanma Barranquero]

On 10/19/06, Frank Schmitt <ich@frank-schmitt.net> wrote:

> If gdb had a leader who said "we don't ship broken code", gdb developers
> would be at annoyed because their favorite new feature of which they are
> proud and fond isn't released to the public and would eventually sit
> down and fix it

Or leave GDB and look for another project more to their tastes. Or
fork the project. Or overthrow the leader :)

> just as it happens in Emacs.

<cough> <cough>

-- 
                    /L/e/k/t/u

Re: Bug Database?

[Nick Roberts]

 > So basically what had to be done is: If you make the lookup between line
 > in source code and offset in object code, look if you are in a templated
 > function, if yes search for all matching offsets in object code instead
 > of only the first one. I looked at the code and while I wasn't able to
 > do the fix myself, I think for someone who knows gdb's internal, the fix
 > wouldn't be much work.
 > 
 > If gdb had a leader who said "we don't ship broken code", gdb developers
 > would be at annoyed because their favorite new feature of which they are
 > proud and fond isn't released to the public and would eventually sit
 > down and fix it, just as it happens in Emacs.

This is armchair advocacy.  I suspect that the fix isn't as easy as you
suggest, but if you feel that strongly about it, you could work on a fix.

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

Re: Bug Database?

[Miles Bader]

Frank Schmitt <ich@frank-schmitt.net> writes:
> Which results in the fact that gdb is since years completely unusable
> for C++ programs relying on templated functions. 

Well, while I'll admit that the last I looked[*] the gdb internals were
awful, unreadable, and barely maintainable code, this statement simply
isn't true.

[*] Many years ago, so take this with a grain of salt.

I spend lots of time debugging heavily templated C++ code in gdb, and
basically there are few problems (other than the canonical "optimized
code can be confusing in the debugger" issues).  While debugging around
templates requires a bit of knowledge about what's actually going on,
it's no different than many other general debugging problems; you run
into minor annoyances, and you quickly find ways around them.

> So most C++ developers I know have switched to the "free as in free
> beer but not free as in free software" debugger from Sun Studio which
> in contrast to gdb works really well.

I suspect this has more to do with the sort of developers you know than
with gdb.

-Miles

-- 
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.

Re: Bug Database?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 19 Oct 2006 02:41:00 -0400
> Cc: emacs-devel@gnu.org
> 
> If we are to run a bug tracker, we first need to work out a plan for
> entering bugs reported by email into the data base.

Usually, it's the other way around: the bugs are reported to the
bug-tracker, which then emails them to the list.

We could modify report-emacs-bug to use a Web browser (via url, for
example) to do that.

Re: Bug Database?

[Eli Zaretskii]

> From: Frank Schmitt <ich@frank-schmitt.net>
> Date: Thu, 19 Oct 2006 09:04:55 +0200
> 
> Which results in the fact that gdb is since years completely unusable
> for C++ programs relying on templated functions (so basically all C++
> programs which aren't just pimped C). 

That's because the GCC developers don't care a bit about having their
newest and hottest features being debuggable with GDB.  GCC leaves an
abysmally inadequate record of its program transformations in the
debug info, which GDB then needs to unlock somehow.  In some
situations this is very hard, in others it's plain impossible.

But I fail to see how all this digression is relevant to Emacs and its
bug tracker.

Re: Bug Database?

[Richard Stallman]

    Only significant bugs that can't be immediately fixed need to be entered,
    although it wouldn't matter if others were too as they can easily be closed.

I agree that "enter bugs if not fixed immediately" would give results,
but it still takes work.  Who wants to do this work?

    You could just see it as an additional tool.  As a start why not just ask the
    Savannah Hackers to turn on the bug tracker for Emacs?  Then people who want to
    use it could file bugs there, and you could keep your own record in
    FOR-RELEASE.

This much would be easy to do.  Would this result in having some bugs
in the bug tracker and other bugs reported on bug-gnu-emacs?

If we did not systematically enter the emailed bug reports into the
bug tracker, would confusion result?

Re: Bug Database?

[Richard Stallman]

    It seems like the sort of job that could easily be automated by a 
    script.

Do people get good results, doing this automatically with a script?
That would be a fine solution if it works.

I was worried about spam, but maybe people are already moderating
these lists to remove the spam.

Re: Bug Database?

[Eli Zaretskii]

> From: Frank Schmitt <ich@frank-schmitt.net>
> Date: Thu, 19 Oct 2006 13:46:35 +0200
> 
> If gdb had a leader who said "we don't ship broken code", gdb developers
> would be at annoyed because their favorite new feature of which they are
> proud and fond isn't released to the public

You are forgetting that GDB is used not only to debug C++ programs.
I'm not sure delaying GDB releases until C++ support is completely
fixed is not too harsh towards C developers, say, especially since no
one has a clear vision of how this C++ monstrocity can be fixed in
some reasonable way (witness the related discussions on the GDB
lists).  Of course, if you know how to do that, I'm sure patches will
be welcome.

Re: Bug Database?

[Yavor Doganov]

В Thu, 19 Oct 2006 21:30:06 +1300, Nick Roberts написа:

> As a start why not just ask the Savannah Hackers to turn on the bug
> tracker for Emacs?

That's not necessary, the project admins can activate it.

> Then people who want to use it could file bugs there, and you could
> keep your own record in FOR-RELEASE.

I anticipate that what RMS (and possibly others who work mostly
offline) means is that setting up such a bug tracker will require
extra efforts, and possibly will lead to duplicated entries.  Perhaps
it will confuse users too, as there will be two ways to report bugs
and they won't know which is the canonical one.

IMVHO, what's needed is a bug tracking system that is entirely
controlled by email.  Thus, people like RMS will continue to work as
now, and it will be possible to query/search the BTS.  AFAIK, only
debbugs offers this (and partly RT, but assigning/resolving bugs
depends on the web interface).

Re: Bug Database?

[Nick Roberts]

 >     Only significant bugs that can't be immediately fixed need to be entered,
 >     although it wouldn't matter if others were too as they can easily be closed.
 > 
 > I agree that "enter bugs if not fixed immediately" would give results,
 > but it still takes work.  Who wants to do this work?

Presumably whoever is interested in seeing the bug fixed, the original poster,
a developer who can't see a fix, I don't know.

 >     You could just see it as an additional tool.  As a start why not just
 >     ask the Savannah Hackers to turn on the bug tracker for Emacs?  Then
 >     people who want to use it could file bugs there, and you could keep your
 >     own record in FOR-RELEASE.
 > 
 > This much would be easy to do.  Would this result in having some bugs
 > in the bug tracker and other bugs reported on bug-gnu-emacs?
 > 
 > If we did not systematically enter the emailed bug reports into the
 > bug tracker, would confusion result?

These questions can only be answered by trying a tracker out.  I can only say
in GDB it helps me find (and fix) old bugs that I probably wouldn't know about
through the archives.

It's now over five years since the last (mainline) release.  I think a tracker
will help with the release cycle.  If you think Emacs should be bug free no
matter how long it takes to make a release, then I guess a tracker may not be
of much use.

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

Re: Bug Database?

[Richard Stallman]

     > If gdb had a leader who said "we don't ship broken code", gdb developers
     > would be at annoyed because their favorite new feature of which they are
     > proud and fond isn't released to the public and would eventually sit
     > down and fix it, just as it happens in Emacs.

    This is armchair advocacy.  I suspect that the fix isn't as easy as you
    suggest, but if you feel that strongly about it, you could work on a fix.

He did not say anything about the amount of work required.  Whether it
is easy or hard affects what the project leaders need to do, but
either way they should exercise leadership to get it fixed.

Re: Bug Database?

[Nick Roberts]

 >      > If gdb had a leader who said "we don't ship broken code", gdb
 >      > developers would be at annoyed because their favorite new feature of
 >      > which they are proud and fond isn't released to the public and would
 >      > eventually sit down and fix it, just as it happens in Emacs.
 > 
 >     This is armchair advocacy.  I suspect that the fix isn't as easy as you
 >     suggest, but if you feel that strongly about it, you could work on a fix.
 > 
 > He did not say anything about the amount of work required.  

In the sentence before your quote he said:

 Frank> I looked at the code and while I wasn't able to do the fix myself, I
 Frank> think for someone who knows gdb's internal, the fix wouldn't be much
 Frank> work

 >                                                           Whether it
 > is easy or hard affects what the project leaders need to do, but
 > either way they should exercise leadership to get it fixed.

Templates aren't GDB's only shortcoming.  I could say GDB/MI is broken.  Others
would say it's weak at debugging multi-threaded programs.  Frank appears to be
saying "I want GDB to work well with C++ templates but I don't want to work on
it, so somebody else should or we should make life unpleasant for them.".
Maybe annoying the people who do contibute to free software is exercising
leadership, I wouldn't know.

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

Re: Bug Database?

[Jason Rumney]

Richard Stallman wrote:
>     It seems like the sort of job that could easily be automated by a 
>     script.
>
> Do people get good results, doing this automatically with a script?
> That would be a fine solution if it works.
>
> I was worried about spam, but maybe people are already moderating
> these lists to remove the spam.
>
>   
If the script only entered bug reports that it could parse an Emacs 
version number out of, then that should prevent spam from getting into 
the bug database. It would still leave some bug reports that needed to 
be manually entered, but at least the workload for the volunteers who 
enter bug reports would be reduced.

Re: Bug Database?

[Richard Stallman]

    Usually, it's the other way around: the bugs are reported to the
    bug-tracker, which then emails them to the list.

But we need to provide for people to continue reporting bugs by email.

    We could modify report-emacs-bug to use a Web browser (via url, for
    example) to do that.

That is no good.  It wouldn't work at all unless there is an active
net connection at the moment.

Re: Bug Database?

[Frank Schmitt]

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

>  > He did not say anything about the amount of work required.  
>
> In the sentence before your quote he said:
>
>  Frank> I looked at the code and while I wasn't able to do the fix myself, I
>  Frank> think for someone who knows gdb's internal, the fix wouldn't be much
>  Frank> work
>
>  >                                                           Whether it
>  > is easy or hard affects what the project leaders need to do, but
>  > either way they should exercise leadership to get it fixed.
>
> Templates aren't GDB's only shortcoming.  I could say GDB/MI is broken.  Others
> would say it's weak at debugging multi-threaded programs.  Frank appears to be
> saying "I want GDB to work well with C++ templates but I don't want to work on
> it, so somebody else should or we should make life unpleasant for them.".
> Maybe annoying the people who do contibute to free software is exercising
> leadership, I wouldn't know.

What I wanted to state is: A free project (especially if it doesn't have
any capable free competitors (like gcc, gdb, the Linux kernel, to a
lesser degree Mozilla)) has a responsibility to deliver code which
fulfills the promises regarding functionality the project makes. Gdb
states that it "allows you to see what is going on `inside' another
program while it executes" and that "The program being debugged can be
written in C, C++, Pascal, Objective-C (and many other languages)".

Telling the user base "If you want the software to behave as advertised,
fix it" is both common in free software and bad style as most users just
can't do this.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Bug Database?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: lekktu@gmail.com, emacs-devel@gnu.org
> Date: Fri, 20 Oct 2006 06:26:49 -0400
> 
> But we need to provide for people to continue reporting bugs by email.
> 
>     We could modify report-emacs-bug to use a Web browser (via url, for
>     example) to do that.
> 
> That is no good.  It wouldn't work at all unless there is an active
> net connection at the moment.

I don't see why that would be any worse than what we have now.  First,
not every email setup works off-line, either.  Second, there are Web
browsers that, like some email software, _can_ be set to work
off-line.  Third, most users have active net connections most of the
time.  And forth, almost no one in their right mind will try sending a
bug report via the net when they know they have no net connection.

Re: Bug Database?

[Eli Zaretskii]

> From: Frank Schmitt <ich@frank-schmitt.net>
> Date: Fri, 20 Oct 2006 14:01:31 +0200
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> What I wanted to state is: A free project (especially if it doesn't have
> any capable free competitors (like gcc, gdb, the Linux kernel, to a
> lesser degree Mozilla)) has a responsibility to deliver code which
> fulfills the promises regarding functionality the project makes. Gdb
> states that it "allows you to see what is going on `inside' another
> program while it executes" and that "The program being debugged can be
> written in C, C++, Pascal, Objective-C (and many other languages)".

And it fulfills that promise.

But what on Earth does all this have to do with an Emacs bug database
issue???

Re: Bug Database?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Frank Schmitt <ich@frank-schmitt.net>
>> Date: Thu, 19 Oct 2006 13:46:35 +0200
>> 
>> If gdb had a leader who said "we don't ship broken code", gdb developers
>> would be at annoyed because their favorite new feature of which they are
>> proud and fond isn't released to the public
>
> You are forgetting that GDB is used not only to debug C++ programs.
> I'm not sure delaying GDB releases until C++ support is completely
> fixed is not too harsh towards C developers,

Which is basically what lead to the egcs fork at one time.  C++ is
really a handicap.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Bug Database?

[Michael Olson]

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

Richard Stallman <rms@gnu.org> writes:

>     Yes, but I'm also suggesting use of a bug database to ensure
>     that reported bugs don't get lost.  That has also come up before
>     and was considered unnecessary, but at that time reported bugs
>     were only recorded in the archives.
>
> It would be useful to run a bug tracker, but I have never done so, and
> I don't know what work for us is required.  Do we transfer the bugs
> into the tracker by hand?  If so, who wants to do that?

You could just use Savannah's bug-tracker by enabling it on Emacs'
project page (https://savannah.gnu.org/projects/emacs/).

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC
 |_] | \| |_| Reclaim your digital rights by eliminating DRM.
      See http://www.defectivebydesign.org/what_is_drm for details.

[-- 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: Bug Database?

[Giorgos Keramidas]

On 2006-10-20 11:19, Miles Bader <miles.bader@necel.com> wrote:
> Frank Schmitt <ich@frank-schmitt.net> writes:
> > Which results in the fact that gdb is since years completely unusable
> > for C++ programs relying on templated functions. 
> 
> Well, while I'll admit that the last I looked[*] the gdb internals were
> awful, unreadable, and barely maintainable code, this statement simply
> isn't true.
> 
> [*] Many years ago, so take this with a grain of salt.
> 
> I spend lots of time debugging heavily templated C++ code in gdb, and
> basically there are few problems (other than the canonical "optimized
> code can be confusing in the debugger" issues).  While debugging around
> templates requires a bit of knowledge about what's actually going on,
> it's no different than many other general debugging problems; you run
> into minor annoyances, and you quickly find ways around them.
> 
> > So most C++ developers I know have switched to the "free as in free
> > beer but not free as in free software" debugger from Sun Studio which
> > in contrast to gdb works really well.
> 
> I suspect this has more to do with the sort of developers you know than
> with gdb.

I am inclined to fully agree with this last statement.

I have had requests (and prepared a patch for the build process/system)
from colleagues in a couple of places (both my current work and earlier
ones), to build programs with the -xs flag of Sun Studio, so that they
can use gdb(1) instead of dbx(1).

What people prefer is, after all, uhm, a `preference' only :)

Re: Bug Database?

[Miles Bader]

Frank Schmitt <ich@frank-schmitt.net> writes:
> Telling the user base "If you want the software to behave as advertised,
> fix it" is both common in free software and bad style as most users just
> can't do this.

Most free software authors are completely honest about what's going on:

  They try their best given a limited amount of manpower, and inevitably
  cannot do everything (it's far easier to think up cool features than
  implement them).  However, because it's free software, users _have the
  ability_ to help the process along.  While not all users have the
  resources to do so (and it doesn't need to be programming expertise --
  e.g. money to hire a programmer will do just as well), this is
  absolutely liberating as a user.

Being honest about the realities of software development is not "bad
style."  [and they are indeed realities -- the vast majority of
commercial software is horribly buggy, but they try their best to hide
that fact under layers of glitz and marketing; of course when the
software is proprietary, the user has few options.]

There is nothing more frustrating for a programmer than using software
with an obvious and simple-to-fix problem, but being helpless to
actually try and do that fix yourself.  Of course things are ten times
more frustrating when the company declares that product dead, and ceases
all future development!  [and these are things that happen _every day_
with commercial software]

It's unfortunate that current cultural trends among computer users has
emphasized the "use and drool, it's all too complicated for me" attitude
among users (because I think the barriers to involvement are mostly
cultural).  Hopefully free software can help reverse this attitude, even
if such change comes slowly.

-Miles

-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: Bug Database?

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> C++ is really a handicap.

C++ (with templates) clearly could have been better in many ways, but
even with all its flaws, is a very nice language for some types of
programming.  [i.e., while I can imagine a more elegant language
offering the same advantages, I don't know of any that are widely
available.  Availability is important too! :-]

Templates+inlining do indeed make things interesting for debuggers, but
as a programmer, I'll put up with some debugging pain if my program
source can be made much more clear as a result.

-Miles

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

Re: Bug Database?

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> Usually, it's the other way around: the bugs are reported to the
> bug-tracker, which then emails them to the list.
>
> We could modify report-emacs-bug to use a Web browser (via url, for
> example) to do that.

While it's nice to have the _ability_ to submit bugs via the web (casual
users might find it easier to deal with such an interface), I think
email reporting is mandatory.  It's also nice to have something like
debian's "reportbug" program, which uses a simple UI on the user's
machine to prompt for details, but sends email to actually report the
bug.  Basically, choice is good.

Several reasons for this:

(1) Email is available in situations where web access is not (the
    reverse is true too of course: again, choice is good).

(2) Typical web bug-tracker interfaces are completely awful (bugzilla,
    I'm looking at you...) and the lack of integretation with one's
    familiar environment annoying.  Clumsy web interfaces are especially
    frustrating when reporting many bugs, because one must painfully
    labor through the same bad interface repeatedly -- when email is
    supported, one can streamline the process greatly (elisp is great
    for this).

(3) Many bugs involve "conversations", with back-and-forth between
    developers (often more than one) and bug reports.  Web-only
    interfaces like bugzilla make this very awkward -- while it wil
    _send_ email to indicate a new response in "the conversation" about
    a bug, one must then go to the web page and fill in a form to reply!
    The natural thing, simply replying (to the email'd report) via one's
    mail client, isn't supported!

-Miles

-- 
"Suppose we've chosen the wrong god. Every time we go to church we're
just making him madder and madder." -- Homer Simpson

Re: Bug Database?

[Richard Stallman]

    If the script only entered bug reports that it could parse an Emacs 
    version number out of, then that should prevent spam from getting into 
    the bug database. It would still leave some bug reports that needed to 
    be manually entered, but at least the workload for the volunteers who 
    enter bug reports would be reduced.

That is true.

To move forward on this, we need someone to make a clear and specific
proposal.

Re: Bug Database?

[Eli Zaretskii]

> Cc: rms@gnu.org,  lekktu@gmail.com,  emacs-devel@gnu.org
> From: Miles Bader <miles@gnu.org>
> Date: Sat, 21 Oct 2006 10:31:59 +0900
> 
> While it's nice to have the _ability_ to submit bugs via the web (casual
> users might find it easier to deal with such an interface), I think
> email reporting is mandatory.  It's also nice to have something like
> debian's "reportbug" program, which uses a simple UI on the user's
> machine to prompt for details, but sends email to actually report the
> bug.  Basically, choice is good.
> 
> Several reasons for this:
> 
> (1) Email is available in situations where web access is not (the
>     reverse is true too of course: again, choice is good).

This goes both ways, as you say.

> (2) Typical web bug-tracker interfaces are completely awful (bugzilla,
>     I'm looking at you...)

I was suggesting a specific interface: the Savannah bug tracker.  I
think its interface is reasonable, please take a look.

> (3) Many bugs involve "conversations", with back-and-forth between
>     developers (often more than one) and bug reports.  Web-only
>     interfaces like bugzilla make this very awkward -- while it wil
>     _send_ email to indicate a new response in "the conversation" about
>     a bug, one must then go to the web page and fill in a form to reply!
>     The natural thing, simply replying (to the email'd report) via one's
>     mail client, isn't supported!

I don't see this as such a disadvantage: if you do both through Emacs,
why does it matter?

Anyway, while there are disadvantages to what I suggested, there's one
very significant advantage: we can use the Savannah bug tracking
interface, which is already used by quite a few projects and is
maintained by the FSF personnel.  The other solutions will require us
to invent everything and will put a much more serious burden on the
Emacs maintenance team.  What if whoever volunteers for this job will
some day become unavailable?  A bug-tracking system is not something
that we can afford to be down.

Re: Bug Database?

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

>     The natural thing, simply replying (to the email'd report) via one's
>     mail client, isn't supported!

Actually some do, like GCC's bugzilla.

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: Bug Database?

[Richard Stallman]

      And forth, almost no one in their right mind will try sending a
    bug report via the net when they know they have no net connection.

I agree with you, but I am concerned about a different point.
I am worried that they will NOT SEND the bug report.

Re: Bug Database?

[Richard Stallman]

    (3) Many bugs involve "conversations", with back-and-forth between
	developers (often more than one) and bug reports.  Web-only
	interfaces like bugzilla make this very awkward -- while it wil
	_send_ email to indicate a new response in "the conversation" about
	a bug, one must then go to the web page and fill in a form to reply!
	The natural thing, simply replying (to the email'd report) via one's
	mail client, isn't supported!

This implies that I would usually be unable to mark a bug report
closed in Bugzilla.  I would usually have to email someone else to do
it for me.  I don't like that.

Re: Bug Database?

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> (2) Typical web bug-tracker interfaces are completely awful (bugzilla,
>>     I'm looking at you...)
>
> I was suggesting a specific interface: the Savannah bug tracker.  I
> think its interface is reasonable, please take a look.

Yes, I've used it quite a bit.  It suffers from the usual problems of
web interfaces -- for filing lots of bugs, it was quite painful (often I
would want to file like 10 bugs simultaneously, and I had fill in ever
single damn field again and again... I really grew to hate the savannah
bug tracker after a while).

It's obvious that there are advantages to both, which is why I'd
_really_ want a system that _does both_ (e.g., email and the web GUI are
different interfaces to the same core system).  And indeed, I know, no
particularly great packages that satisfy that.  It sucks, but there you
have it.

-Miles
-- 
Run away!  Run away!

Re: Bug Database?

[Miles Bader]

Andreas Schwab <schwab@suse.de> writes:
>>     The natural thing, simply replying (to the email'd report) via one's
>>     mail client, isn't supported!
>
> Actually some do, like GCC's bugzilla.

Cool!  That would be a wonderful improvement over "classic" bugzilla.
Maybe that's a system worth considering?

-Miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: Bug Database?

[Richard Stallman]

    Actually some do, like GCC's bugzilla.

Could you tell us more?  Does Savannah need to install the version
of Bugzilla that GCC uses, in order to provide the same capability?

Re: Bug Database?

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     Actually some do, like GCC's bugzilla.
>
> Could you tell us more?  Does Savannah need to install the version
> of Bugzilla that GCC uses, in order to provide the same capability?

Savannah does not use Bugzilla, AFAIK.

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: Bug Database?

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>>> (2) Typical web bug-tracker interfaces are completely awful (bugzilla,
>>>     I'm looking at you...)
>>
>> I was suggesting a specific interface: the Savannah bug tracker.  I
>> think its interface is reasonable, please take a look.
>
> Yes, I've used it quite a bit.  It suffers from the usual problems of
> web interfaces -- for filing lots of bugs, it was quite painful (often I
> would want to file like 10 bugs simultaneously, and I had fill in ever
> single damn field again and again... I really grew to hate the savannah
> bug tracker after a while).

When was the last time you filed 10 bugs simultaneously to the Emacs
bug list?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Bug Database?

[Richard Stallman]

    > Could you tell us more?  Does Savannah need to install the version
    > of Bugzilla that GCC uses, in order to provide the same capability?

    Savannah does not use Bugzilla, AFAIK.

What bug tracker does Savannah use?

Re: Bug Database?

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> What bug tracker does Savannah use?

Why not ask the savannah hackers?  How should I know?

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: Bug Database?

[Sascha Wilde]

Yavor Doganov <yavor@doganov.org> wrote:

> IMVHO, what's needed is a bug tracking system that is entirely
> controlled by email.  Thus, people like RMS will continue to work as
> now, and it will be possible to query/search the BTS.  AFAIK, only
> debbugs offers this (and partly RT, but assigning/resolving bugs
> depends on the web interface).

I do strongly agree, that a tracker that supports full control via
email is needed. 

I would suggest roundup as a possible candidate, which allows any
option, which can be set in the web interface to be set via a simple
keyword in the subject line of emails, too.

cheers
sascha
-- 
Sascha Wilde

Programmer - A red-eyed, mumbling mammal capable of conversing with
             inanimate objects.

Re: Bug Database?

[Alfred M. Szmidt]

       > Could you tell us more?  Does Savannah need to install the
       > version of Bugzilla that GCC uses, in order to provide the
       > same capability?

That would be the case, yes.  Or add such features to the bug tracker
that Savannah is using.

       Savannah does not use Bugzilla, AFAIK.

   What bug tracker does Savannah use?

They use the one included in Savane (it doesn't have a special name).
It is also web-based only, so you cannot use email to enter, or reply
to bug reports.

There is also GNATS, the GNU Bug Tracker System.  But I don't know the
difference between GNATS and Bugzilla to comment about it.

Re: Bug Database?

[Richard Stallman]

    > What bug tracker does Savannah use?

    Why not ask the savannah hackers?  How should I know?

Since you said it wasn't Bugzilla, I thought you did know.
I am going to write to them about the issue, but I figured
if you knew I could ask you first.

Re: Bug Database?

[Richard Stallman]

Thanks for the info.
Now I know what to say to the savannah hackers.