From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.devel Subject: Re: Handling BUGS. Date: Fri, 22 Mar 2002 11:13:09 -0800 Sender: guile-devel-admin@gnu.org Message-ID: References: <87g02t4zgn.fsf@raven.i.defaultvalue.org> <87lmcko60l.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us> Reply-To: ttn@glug.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1016824703 5547 127.0.0.1 (22 Mar 2002 19:18:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 22 Mar 2002 19:18:23 +0000 (UTC) Cc: guile-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16oUYQ-0001R9-00 for ; Fri, 22 Mar 2002 20:18:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16oUYC-0004PK-00; Fri, 22 Mar 2002 14:18:08 -0500 Original-Received: from ca-crlsbd-u3-c5c-122.crlsca.adelphia.net ([68.64.59.122] helo=giblet) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16oUWE-0004Iz-00 for ; Fri, 22 Mar 2002 14:16:06 -0500 Original-Received: from ttn by giblet with local (Exim 3.33 #1 (Debian)) id 16oUTN-0002s4-00; Fri, 22 Mar 2002 11:13:09 -0800 Original-To: evan@glug.org Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:153 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:153 From: Evan Prodromou 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