Re: [Bashdb-devel] bashdb.el

[Rocky B. <roc...@gm...>]

Advantages of not being part of GNU Emacs

   - easier to affect a change (at least for me)
   -  more frequent releases for users
   - shorter turn-around time when a problem is found or an
   improvement/patch offered

Some of the advantages may vary over time. In particular, bashdb releases
are currently much more frequent that GNU Emacs releases. Will that always
be the case? I don't know. However since bashdb is much much smaller than
GNU Emacs, it stands a good chance of being true.

The  turn-around time to address/fix a problem is also a dynamically
changeable thing. Above I'm just observing that this is what the
currentsituation seems to be.

Disadvantages of not being part of GNU Emacs

   -  People are more knowledgeable about the workings of GNU Emacs ,
   GUD, and Emacs Lisp than most bashdb  folks are
   -  When GUD and GNU Emacs change, this code will get updated in
   conjunction with that (we hope) so...
   - Easier to keep code consistent with the currently installed GNU
   Emacs. In bashdb I guess some compatibility needs to happen across
   many  GNU Emacses

Given the above advantages and disadvantages, I think the advantages of not
being part of GNU Emacs outweigh the disadvantages. But I'd like to hear the
comments of others. Should this be cross-posted to the emacs newsgroups  and
emacs developers groups?

And by they way, isn't there also a bashdb.el that gets distributed with
BASH?

Let me close, by relating something that caused me to change bashdb.el. In a
way it fleshes out in detail some of the points above.

Recently someone reported a regexp problem in the pydb -equivalent Emacs
program. As part of fixing that, I decided we really should start adding a
regression test for this. As best as I can tell there are no unit tests for
GNU Emacs, and in fact I think one of Richard Stallman's complaints is that
folks aren't testing things in GNU Emacs. So I went over the regular
expression pattern in bashdb.el and added a unit test, at least for the part
that had been a bug.

I suppose I should have sent another patch for GNU Emacs, but the last time
I put in a patch it wasn't all that satisfying or quick. I had to send some
copyright release thing (having done so several times in the past), and I
got a complaint from RMS about how the ChangeLog entry was written,
something about listing function names in a file or something. All of this
spanned about a month.

And after all of that work, none of that code has seen light of day in terms
of a general release. So the thing I care about most really hasn't happened
(yet). And as we see, when it happens it will likely be obsolete code
because of the hassle (at least for me) of keeping this code up to date.

On 1/21/07, Masatake YAMATO <je...@gy...> wrote:
>
> There are two M-x bashdb; one is distributed as part of bashdb, and
> another will be distributed as part of the next version of GNU emacs.
> I guess the users may be confused.
>
> What is the best way to deal this situation?
> My opinion is that it is better to remove M-x bashdb code from GNU emacs.
> In stead I will add some code to the bashdb.el distributed as part of
> bashdb to make it work well with the CVS version of GNU Emacs.
>
> Rocky, how do you think?
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>