Handling BUGS.

Handling BUGS.

[Rob Browning]

What about a semi-trivial upgrade to our bug handling infrastructure?

  (1) create a top level guile CVS module called guile-bugs.

  (2) create a shallow directory tree:
        guile-bugs/active/
        guile-bugs/resolved/

  (3) create a new file in active/ per bug containing the current
      contents of it's entry in 1.5/BUGS or 1.7/BUGS -- merge any
      duplicates.  (a simple 'ls | sort -n | tail -1" can tell us what
      the next bug number should be)

  (4) Add an "affects" field to every bug, and whenever a bug's
      "affects" field becomes empty, move it to resolved/.  The
      affects field would be something like: "affects: 1.4 1.5 1.7" or
      perhaps (affects "1.4" "1.5" "1.7") -- not sure if scheme-forms
      would buy us anything we care about...

  (5) modify the RELEASE process to require that a current BUGS file
      be generated from guile-bugs and added to the release CVS tree
      at release time (just before tagging the release).  This file
      would be (auto)generated from guile-bugs/active based on the
      contents of the "affects" fields.

  (6) add a note to the top of the auto-generated BUGS files
      indicating that they're auto-generated and pointing people at
      the guile-bugs CVS module and/or any web pages we might
      auto-generate from guile-bugs.

This seems like it would be a lot more flexible than what we have now,
and shouldn't be much work.

Thoughts?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Neil Jerram]

>>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> writes:

    Rob> What about a semi-trivial upgrade to our bug handling
    Rob> infrastructure?

All sounds good to me, but how do we indicate that a bug has been
fixed in one tree but not in another?

        Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> All sounds good to me, but how do we indicate that a bug has been
> fixed in one tree but not in another?

Just change it's "affects:" field.  i.e. you could have

  affects: 1.4 1.6 1.7

and when it's fixed in 1.6, just delete it from the line.  The only
time a bug would move to resolved is if it's been fixed in *all*
trees.  In this first, fairly simplistic approach, I mostly just
figured resolved as a place old bugs go to die to at least *somewhat*
reduce the inevitable clutter we'll have in active.  In the long term,
pumping this stuff into postgres via guile-pg or similar may be the
way to go, but that's a problem for our future selves :>

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Neil Jerram]

>>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> writes:

    Rob> Neil Jerram <neil@ossau.uklinux.net> writes:
    >> All sounds good to me, but how do we indicate that a bug has been
    >> fixed in one tree but not in another?

    Rob> Just change it's "affects:" field.  i.e. you could have

    Rob>   affects: 1.4 1.6 1.7

    Rob> and when it's fixed in 1.6, just delete it from the line.  The only
    Rob> time a bug would move to resolved is if it's been fixed in *all*
    Rob> trees.  In this first, fairly simplistic approach, I mostly just
    Rob> figured resolved as a place old bugs go to die to at least *somewhat*
    Rob> reduce the inevitable clutter we'll have in active.  In the long term,
    Rob> pumping this stuff into postgres via guile-pg or similar may be the
    Rob> way to go, but that's a problem for our future selves :>

That sounds fine.

        Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Thu, 21 Mar 2002 11:12:24 -0600

     (1) create a top level guile CVS module called guile-bugs.
     (2) create a shallow directory tree:
	   guile-bugs/active/
	   guile-bugs/resolved/

how about promote devel/ out of guile-core/ entirely?  it is generally
not related to any specific branch.  bugs housekeeping is part of the
development effort, after all...

     (3) create a new file in active/ per bug [...]
     (4) Add an "affects" field

might as well specify a known format, how about rfc822?  it's time to
see how well the elisp translation machinery holds up to rfc822.el
(moderately hairy load IMHO).  if not, someone will check in rfc822.scm
soon i'm sure.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Neil Jerram]

>>>>> "thi" == Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

    thi> how about promote devel/ out of guile-core/ entirely?  it is
    thi> generally not related to any specific branch.  bugs
    thi> housekeeping is part of the development effort, after all...

That sounds good to me.  It makes sense to me to track both bugs and
future enhancements in a similar kind of way.

(BTW, anyone looking for a data mining job?  There's a goldmine of
useful discussion on future enhancements (which may also be
simplifications, of course) in the mailing list archive.)

    thi> might as well specify a known format, how about rfc822?  it's
    thi> time to see how well the elisp translation machinery holds up
    thi> to rfc822.el (moderately hairy load IMHO).  if not, someone
    thi> will check in rfc822.scm soon i'm sure.

Now you're playing dirty!

Handling rfc822.el will require a basic buffer implementation:
forward-char, insert, buffer-substring etc. etc.  But surely that's a
more interesting task for someone than translating rfc822.el as a
whole to rfc822.scm.

(To make it really interesting/useful, do this by preprocessing the
relevant source files from the Emacs distribution.  (Damn, I'm quite
tempted myself now.))

        Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Rob Browning]

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

> how about promote devel/ out of guile-core/ entirely?  it is generally
> not related to any specific branch.  bugs housekeeping is part of the
> development effort, after all...

Hmm.  I think I can see the motivation, but I can also see the value
in having a "complete tree" so that people who grab CVS and want to
hack have all that info on hand.  Not sure.  Would we still ship
updated versions of these files at release time (as I've suggested for
BUGS), or omit them entirely?

> might as well specify a known format, how about rfc822?  it's time to
> see how well the elisp translation machinery holds up to rfc822.el
> (moderately hairy load IMHO).  if not, someone will check in rfc822.scm
> soon i'm sure.

Very sneaky :> I like it...

On a semi-related note, and FWIW, eventually I'd like to be able to
manipulate the bug system via email (gpg signed perhaps), and perhaps
also via the web.  But for now, I think we'd be fine with just some
slight improvements.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Fri, 22 Mar 2002 08:25:08 -0600

   Hmm.  I think I can see the motivation, but I can also see the value
   in having a "complete tree" so that people who grab CVS and want to
   hack have all that info on hand.  Not sure.

we can effect logical inclusion while maintaining modularity by moving
devel/ up, and modifing CVSROOT/modules to add:

guile-plus-devel	&guile-core &devel

(i'll have to check syntax on this, and if we can actually modify
CVSROOT/modules -- anyone know for sure?)

   Would we still ship updated versions of these files at release time
   (as I've suggested for BUGS), or omit them entirely?

it's my understanding that devel/ is not included in "make dist" at all,
which seems right.  all the more reason to unbundle it, IMHO.  including
some form of bugs summary in top-level file BUGS is standard but we need
not distribute that info in the form we maintain it (it can be generated
as suggested).

   On a semi-related note, and FWIW, eventually I'd like to be able to
   manipulate the bug system via email (gpg signed perhaps), and perhaps
   also via the web.  But for now, I think we'd be fine with just some
   slight improvements.

modifying a file under cvs is comfortable to me.  i had weird experience
administering web-based bug tracking (bugzilla) -- sometimes users (in
this case ASIC (hardware) engineers) would press the "back" button on
their browser and resubmit forms that would confuse the system (to put
it charitably) -- so i'm not a big fan of that approach.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Evan Prodromou]

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

>>>>> "RB" == Rob Browning <rlb@defaultvalue.org> writes:

    RB> What about a semi-trivial upgrade to our bug handling
    RB> infrastructure?

Not my place to say, but: the system you're suggesting isn't going to
be The Right Thing, nor will it be particularly easier to work with or
more complete with than what you have now.

I would say that any time or effort devoted to hacking on a quasi
bug-tracking system would be better spent putting bugs in the current
system, tracking them, and fixing them for 1.6 release.

After that release, start using savannah's Sourceforge bug-tracker, or
build one that's all the way "right" with Guile.

In other words, concentrate on the release, not the bug-tracking
"tool". What you're suggesting gives everyone an excuse to ignore the
BUGS file and (totally insufficient) system in place until the "next"
system appears.

OK, that's my advice. Take it however you want.

~ESP

-- 
Evan Prodromou
evan@glug.org

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

Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Evan Prodromou <evan@glug.org>
   Date: Fri, 22 Mar 2002 11:40:26 -0600

   In other words, concentrate on the release, not the bug-tracking
   "tool". What you're suggesting gives everyone an excuse to ignore the
   BUGS file and (totally insufficient) system in place until the "next"
   system appears.

well, it seems to me release includes integrating bug summaries into the
tarball, and writing tools to reduce manularity is a wise investment.

the protocol of editing a file and checking it into CVS seems to work
for many things, including bug tracking.  however, maintaining the bugs
database per branch is not a good idea (i confess to being the one who
set up BUGS there -- a case of poor planning).

what is being proposed is moving that file (and similar non branch
specific files, if i get my druthers) elsewhere, in the process refining
the BUGS format to make it easier for tools, as well as tweaking the
release process to DTRT.  this change does not affect the above
described protocol, only the implementation (ie, it is indeed trivial).

so i would have to disagree w/ your point, but obliquely; it is
precisely the act of concentrating on release that is the motivating
factor here, and it seems the proposed changes are well thought-out,
or in the process of becoming so.

when you say "it is more important to do this than that" you lose sight
of the fact that parallel effort is possible and indeed encouraged --
good project manglement is not so much about constraining (controlling,
contorting) efforts into a single thread, but more about defining a
future sync point where the multiple threads can come together (in a
harmonious way hopefully).  there are dependencies certainly, but
resolution is possible -- therein lies the artistry.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Evan Prodromou]

>>>>> "TN" == Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

    Me> In other words, concentrate on the release, not the
    Me> bug-tracking "tool". What you're suggesting gives everyone an
    Me> excuse to ignore the BUGS file and (totally insufficient)
    Me> system in place until the "next" system appears.

    TN> so i would have to disagree w/ your point, but obliquely; it
    TN> is precisely the act of concentrating on release that is the
    TN> motivating factor here, and it seems the proposed changes are
    TN> well thought-out, or in the process of becoming so.

Well, then, if that's the case, I'd say go for it.

HOWEVER, it seems that perhaps maintaining the current bug file format
(except, of course, splitting up bugs between files) might get one
"there" faster than hoping for -- or hacking on -- an RFC822 parser.

    TN> when you say "it is more important to do this than that" you
    TN> lose sight of the fact that parallel effort is possible and
    TN> indeed encouraged -- good project manglement is not so much
    TN> about constraining (controlling, contorting) efforts into a
    TN> single thread, but more about defining a future sync point
    TN> where the multiple threads can come together (in a harmonious
    TN> way hopefully).

This is true. However, good _release_ management has everything to do
with prioritizing energy and focus, and having dependable
processes. 

~ESP

-- 
Evan Prodromou
evan@glug.org

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Evan Prodromou <evan@glug.org>
   Date: Fri, 22 Mar 2002 13:40:01 -0600

   HOWEVER, it seems that perhaps maintaining the current bug file format
   (except, of course, splitting up bugs between files) might get one
   "there" faster than hoping for -- or hacking on -- an RFC822 parser.

usable rfc822 parsers have already been written (by at least two people
on this mailing list, probably everyone has one in their personal tool
kit).  the program you posted for html-izing BUGS can be easily refitted
to use one of these parsers.  why don't you do this instead of trying to
convince other people not to do this?  it would be very helpful.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Evan Prodromou]

>>>>> "TN" == Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

    TN> why don't you do this instead of trying to convince other
    TN> people not to do this?  it would be very helpful.

You're assuming that I want to be helpful more than I want to
rant. B-)

But, OK. I'll re-write the bugs parser thingy, as well as a converter
to move from the current format to a new RFC format. Can I define the
headers for Bug files? Please?

~ESP

-- 
Evan Prodromou
evan@glug.org

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Evan Prodromou <evan@glug.org>
   Date: Fri, 22 Mar 2002 12:34:17 -0800

   You're assuming that I want to be helpful more than I want to
   rant. B-)

true.  ranting is in some respects helpful.  now that you've waxed on,
the next step is to wax off...

   But, OK. I'll re-write the bugs parser thingy, as well as a converter
   to move from the current format to a new RFC format. Can I define the
   headers for Bug files? Please?

probably since Rob has detailed some plans already he can give you
better direction here.  i suppose it was uncool of me to suggest you do
something that he may have already started doing.

if Rob has this initiative staked out but you're still interested in
codified ranting (as any sane person would be ;-), i have suggestions on
other ways to align your wishlist w/ current efforts.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Rob Browning]

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

> probably since Rob has detailed some plans already he can give you
> better direction here.  i suppose it was uncool of me to suggest you do
> something that he may have already started doing.

Nope.  I just wanted to discuss it (in parallel with other things) so
we'd know where we were going.  I'm happy (and was hoping) other
people might be willing to work on it.

> if Rob has this initiative staked out but you're still interested in
> codified ranting (as any sane person would be ;-), i have suggestions on
> other ways to align your wishlist w/ current efforts.

I don't have strong feelings about the fields we'll eventually want.
I'm *very* happy to start simple and add things as we need them.  One
advantage to having everything in CVS with well defined headers is
that it should be pretty easy to rearrange things via a guile script
when we know more about what we want.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Fri, 22 Mar 2002 16:33:49 -0600

   Nope.  I just wanted to discuss it (in parallel with other things) so
   we'd know where we were going.  I'm happy (and was hoping) other
   people might be willing to work on it.

ok, if no one objects, i will delete devel/ from guile-core/ and move
its contents to sibling cvs module "devel".  when Evan posts the BUGS
exploder script (or if i stumble on some emacs keyboard macro, whichever
happens first), we will use that to create devel/bugs/, one bug per file
therein.

when Evan posts the summarization script (to create BUGS for release and
html suitable for web publishing), we can add it to scripts/ (or to
../guile-scripts/ if there are paperwork problems), modify RELEASE to
include instructions on when and how to run that script, and then delete
BUGS from cvs (all branches).

in the meantime, i'll look into adding something to CVSROOT/modules,
and/or modify ANON-CVS w/ instructions on how to check out devel/ in
addition to guile-core/.  fyi, i was able to do:

  cvs -d :ext:ttn@subversions.gnu.org:/cvsroot/guile co CVSROOT
  cd CVSROOT
  cvs edit modules

(btw, i agree that all of this is independent of release schedule.  as
long as we include some BUGS file w/ relevant info i'm happy.  i'm eager
to put this into place quickly, however, because there are several bugs
i'd like to add to the system -- including some that i started to look
into but haven't figured out yet -- and would prefer to just add them in
one place.  maybe i should add them to 1.6 BUGS now.)

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Marius Vollmer]

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

> ok, if no one objects, i will delete devel/ from guile-core/ and move
> its contents to sibling cvs module "devel".

What about calling it "workbook" instead of "devel"?

Ohter than that, I think it is a very good idea to move devel out of
the sources into its own module.  It doesn't make sense to have it in
the branches.

> when Evan posts the BUGS exploder script (or if i stumble on some
> emacs keyboard macro, whichever happens first), we will use that to
> create devel/bugs/, one bug per file therein.

I have a slightly uneasy feeling about splitting BUGS into multiple
files.  CVS is not very good at moving or renaming files and we
wouldn't have a centralized log any more.  I don't see any problems
with just keeping all bugs in one file.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> I have a slightly uneasy feeling about splitting BUGS into multiple
> files.  CVS is not very good at moving or renaming files and we
> wouldn't have a centralized log any more.  I don't see any problems
> with just keeping all bugs in one file.

That's fine with me too, though I might still want to have an active
and a resolved file -- keep things a little more wieldy.  However,
bear in mind that if we keep logs of discussions regarding bugs with
the bugs (and patches, etc.), the single file might get quite large.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> That's fine with me too, though I might still want to have an active
> and a resolved file -- keep things a little more wieldy.  However,
> bear in mind that if we keep logs of discussions regarding bugs with
> the bugs (and patches, etc.), the single file might get quite large.

Oh, and I had just figured that single files might make it easier to
use sgrep and other tools to find what you want, but I suspect we
could easily develop similar tools ourselves, so that's not a
super-strong argument either.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> > I have a slightly uneasy feeling about splitting BUGS into multiple
> > files.  CVS is not very good at moving or renaming files and we
> > wouldn't have a centralized log any more.  I don't see any problems
> > with just keeping all bugs in one file.
> 
> That's fine with me too,

I now think having one file per bug is OK as well and I think we
should go that route.

> though I might still want to have an active
> and a resolved file -- keep things a little more wieldy.

'Active' and 'resolved' is only one of many possible categorizations.
It might be the most important one, now, but categorizing bugs
according to severity, affected release, or assigned developer might
be useful as well.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 23 Mar 2002 13:14:15 +0100

   What about calling it "workbook" instead of "devel"?

that's fine by me.

   I have a slightly uneasy feeling about splitting BUGS into multiple
   files.  CVS is not very good at moving or renaming files and we
   wouldn't have a centralized log any more.  I don't see any problems
   with just keeping all bugs in one file.

usually a bug, once interned into the system, should not move (and
should not be deleted).  its status and other attributes can change, of
course, but its relationship to the filesystem need not.  this property
is important; new bugs that are duplicates of, or related to, old bugs
need to be able to refer to old bugs (see bug 6, for example).  same
goes for regression tests.

generally, separating database format from presentation format allows
tuning presentation to everyone's individual taste.  i'm hoping Evan's
bugs renderer will have tasty customization hooks, etc.  a particularly
nice feature would be directory slices:

 cd /tmp
 render-bugs --dir-slice resolved .../workplace/bugs/

creates /tmp/resolved/{3,4,5} (symlinks to .../workplace/bugs/{3,4,5})
where 3,4,5 are determined to satisfy the pre-defined "resolved" filter.

then, you can do further render-bugs on /tmp/resolved/ (perhaps
recursing into /tmp/resolved/1.6/, etc).  when you're done, just rm -rf
/tmp/resolved/.

it would also be nice to accept a predicate for ad-hoc slicing:

 render-bugs --dir-slice-predicate ttn \
               '(equal? (bug-assq (quote reporter)) "ttn")'

bug-assq would need to be provided and other similar primitives.  mixing
pre-defined and ad-hoc reporting like this "allows the simple to be easy
and the complex to be possible" (to further promote a popular meme ;-).
for an example of this kind of reporting, see test-suite/guile-test.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Marius Vollmer]

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

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 23 Mar 2002 13:14:15 +0100
> 
>    What about calling it "workbook" instead of "devel"?
> 
> that's fine by me.

Ok.

>    I have a slightly uneasy feeling about splitting BUGS into multiple
>    files.  CVS is not very good at moving or renaming files and we
>    wouldn't have a centralized log any more.  I don't see any problems
>    with just keeping all bugs in one file.
> 
> usually a bug, once interned into the system, should not move (and
> should not be deleted).

Yes, I was referring to Rob's plan to move resolved bugs into a
different directory.  When we use one file per BUG, we should not put
them into different directories depending on their state.  This would
be nice for a quick overview, but as you say, we can get this with
some simple tools that would also allow for more a flexible
categorization.

>  cd /tmp
>  render-bugs --dir-slice resolved .../workplace/bugs/
> 
> creates /tmp/resolved/{3,4,5} (symlinks to .../workplace/bugs/{3,4,5})
> where 3,4,5 are determined to satisfy the pre-defined "resolved" filter.

This is nice.  What about a Gnus mail backend that works on the bug
data base? ;-)  (Only half joking..)


I see that we already have a workbook/bugs directory (thanks!).  What
about putting the following README into it, as a start:

    This directory is the Guile bug data base.

    It contains one file per bug with a simple, mail-message like
    format.  Each file starts with a number of header lines in the
    form

      field-name: field-value

    where 'field-name' contains no whitespace and is compared
    case-insensitive.  'field-value' can be continued in the next line
    by using a '\' as its last character.  The header is separated
    from the body by a blank line.  The body is the rest of the file.
    There is no limit on the length of a line.

    The following header fields are defined:

      Summary    - a one-line summary of the bug
      Tags       - a comma separated list of symbolic tag names
                   (for example release-critical-1.6)
      Reported-By: savannah-name
      Date: yyyy-mm-dd hh:mm:ss
      [etc.]
    
    If you need more header fields, please document them here.

    The names of the bug files can be chosen arbitrarily, but must
    start with a lower case letter.  If you don't want to use a
    symbolic name, use a name of the form "bug-<n>" where <n> is the
    next unused number.  these names are used to refer to bugs from
    within the description of other bugs, and in discussions, so it
    helps to use mildly descriptive names.

    Meta information about the bug tracking system (like this README
    file) should be put into files that start with a upper case letter.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 24 Mar 2002 14:37:34 +0100

   Yes, I was referring to Rob's plan to move resolved bugs into a
   different directory.  When we use one file per BUG, we should not put
   them into different directories depending on their state.  This would
   be nice for a quick overview, but as you say, we can get this with
   some simple tools that would also allow for more a flexible
   categorization.

ok i understand now.  yes, agreed.  it's the old "how to represent
attributes -- inside or outside" question.

   This is nice.  What about a Gnus mail backend that works on the bug
   data base? ;-)  (Only half joking..)

eventually Gnus interfaces to all trees, so yeah why not?

   I see that we already have a workbook/bugs directory (thanks!).  What
   about putting the following README into it, as a start:

       [field deinition / documentation]

cool.

       The names of the bug files can be chosen arbitrarily, but must
       start with a lower case letter.  If you don't want to use a
       symbolic name, use a name of the form "bug-<n>" where <n> is the
       next unused number.  these names are used to refer to bugs from
       within the description of other bugs, and in discussions, so it
       helps to use mildly descriptive names.

maybe something like bug-000.no-bugs-database ?  we also need to ask
if/how a bug-000.scm (that would exercise the bug) are to be referenced
and/or included in the database.  keeping such code in the databse might
be less work in the long run (it would be easy to extract them into some
regression/ directory for nightly tests).  maybe something like:

  test-cases: ("bug-000.1.scm" "bug-000.2.scm" ...)

       Meta information about the bug tracking system (like this README
       file) should be put into files that start with a upper case letter.

yeah i like easy-to-understand conventions that "ls" handles
automatically.  :->

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Marius Vollmer]

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

>    I see that we already have a workbook/bugs directory (thanks!).  What
>    about putting the following README into it, as a start:
> 
>        [field deinition / documentation]
> 
> cool.

Ok, I will 'implement' this then and move the current BUGS files into
the database.

>        The names of the bug files can be chosen arbitrarily, but must
>        start with a lower case letter.  If you don't want to use a
>        symbolic name, use a name of the form "bug-<n>" where <n> is the
>        next unused number.  these names are used to refer to bugs from
>        within the description of other bugs, and in discussions, so it
>        helps to use mildly descriptive names.
> 
> maybe something like bug-000.no-bugs-database ?

I don't think bugs need numbers, just no-bugs-database should be
enough.

> we also need to ask if/how a bug-000.scm (that would exercise the
> bug) are to be referenced and/or included in the database.

Yes, good point.  What about simply saying that the bug file itself
has no "." in its name, and related files like test scripts do?

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> I don't think bugs need numbers, just no-bugs-database should be
> enough.

On second thought, I completely agree that just having one set of
files is a better idea, though if the bugs database keeps growing, we
might need to archive older stuff at some point -- that's all I was
really thinking of.  However there are probably much better ways to
handle that.

However I *am* a little hesitant about the free-form bug/file-names,
but since I'm having trouble figuring out exactly why that worries me,
we'll just ignore me for now :>

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> On second thought, I completely agree that just having one set of
> files is a better idea, though if the bugs database keeps growing, we
> might need to archive older stuff at some point -- that's all I was
> really thinking of.  However there are probably much better ways to
> handle that.

When we have a mass of bugs in the data base, we'll probably also have
good tools to browse them.  Just looking at them with 'ls' wont scale,
but we don't need to do that.

> However I *am* a little hesitant about the free-form bug/file-names,
> but since I'm having trouble figuring out exactly why that worries
> me, we'll just ignore me for now :>

What worries me slightly is that in a listing like

    README
    autoconf-woes
    autoconf-woes-2
    bug-0
    bug-1
    bug-2
    no-bugs-database
    ...

it might not be apparent that all files describe bugs, not just the
"bug-*" ones.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> it might not be apparent that all files describe bugs, not just the
> "bug-*" ones.

Well, to fix that problem, why not just put all bugs in a bug/
subdirectory, so we'd have:

  README
  Whatever
  Some-other-info
  script/foo
  script/bar
  bug/bug-0
  bug/something
  bug/something-else
  etc...

Maybe we don't need/want script/, or perhaps it should just be bin/,
but I suspect you get the idea...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 24 Mar 2002 21:40:38 +0100

   I don't think bugs need numbers, just no-bugs-database should be
   enough.

numbers are symbolic (see comp.lang.lisp thread on packaging).  they
have extra properties that are useful for ordering and concise to
reference.

   Yes, good point.  What about simply saying that the bug file itself
   has no "." in its name, and related files like test scripts do?

i suggest dot dirs in my other mail (using numbers, but i fancy
N.SHORT-DESC would be the righteous hybrid solution).

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Marius Vollmer]

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

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 24 Mar 2002 21:40:38 +0100
> 
>    I don't think bugs need numbers, just no-bugs-database should be
>    enough.
> 
> numbers are symbolic (see comp.lang.lisp thread on packaging).  they
> have extra properties that are useful for ordering and concise to
> reference.

Whatever.  Let's not unproductively quibble over this.  Let's just say
that numbers are OK, too.

>    Yes, good point.  What about simply saying that the bug file itself
>    has no "." in its name, and related files like test scripts do?
> 
> i suggest dot dirs in my other mail (using numbers, but i fancy
> N.SHORT-DESC would be the righteous hybrid solution).

A directory can be seen as a related file, as well, I'd say: bug-12.stuff/
I'll mention this as well.

I will just trot along in workbook/bugs even if we don't have complete
consensus yet.  I want to use the new mechanism already for better
managing the 1.6 release.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 25 Mar 2002 22:05:36 +0100

   Whatever.  Let's not unproductively quibble over this.  Let's just say
   that numbers are OK, too.

ultimately it is the tools (and whoever writes the tools) that make the
decisions.  our discussion is completely unproductive in its nature, but
hopefully Evan weighs the points brought up and contributes something
that makes you happy (and that you won't go gratuitously re-writing).

   A directory can be seen as a related file, as well, I'd say: bug-12.stuff/
   I'll mention this as well.

   I will just trot along in workbook/bugs even if we don't have complete
   consensus yet.  I want to use the new mechanism already for better
   managing the 1.6 release.

i thought your position was that the new mechanism should not gate 1.6
release.  what made you change your mind?

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Marius Vollmer]

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

> i thought your position was that the new mechanism should not gate
> 1.6 release.  what made you change your mind?

Because the new mechanism was quickly done, and made so much sense,
mostly.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 25 Mar 2002 23:31:02 +0100

   Because the new mechanism was quickly done, and made so much sense,
   mostly.

in that case i will add these bugs shortly:

    - subject: Guile fails tests on Tru64 4.0F
    - subject: failed backtrace

since they manifest in 1.6 and i've started looking into them.  i'll add
"scan mailing list archives for bugs" to tasks/TODO, also.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 25 Mar 2002 23:31:02 +0100

   Because the new mechanism was quickly done, and made so much sense,
   mostly.

in that case i will add these bugs shortly:

    - subject: Guile fails tests on Tru64 4.0F
    - subject: failed backtrace

since they manifest in 1.6 and i've started looking into them.  i take
it we can use whatever conventions we want?  i'm going to try to stick
w/ something like NUMBER-NP-VP (noun phrase, verb phrase), w/ NUMBER
starting at 1000.  maybe other people will use this convention, too.

i've added "scan mailing list archives for bugs" to tasks/TODO, also.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <ttn@giblet.glug.org>
   Date: Fri, 22 Mar 2002 12:08:27 -0800

   the program you posted for html-izing BUGS can be easily refitted to
   use one of these parsers.

or even extended to do rfc822 parsing itself.  go for it!

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Handling BUGS.

[Rob Browning]

Evan Prodromou <evan@glug.org> writes:

> Well, then, if that's the case, I'd say go for it.
>
> HOWEVER, it seems that perhaps maintaining the current bug file format
> (except, of course, splitting up bugs between files) might get one
> "there" faster than hoping for -- or hacking on -- an RFC822 parser.

Right, as a first pass, I just wanted to split the files based on the
^L chars and start with that.

I also felt like this could be done pretty independently of the
release, and in fact, I wasn't planning to work on any of this myself
anytime soon.  It just seemed like a good idea.  (Editing two files
with the same bug with different numbers is something I'm very likely
to screw up.)

When I get ready to release, I either include the current BUGS file,
or the one from guile-bugs, depending on which one exists, and is
more correct :>

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel