Re: Handling BUGS.

[Thien-Thi Nguyen <ttn@giblet.glug.org>]

   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