Re: Modified TODO (and RELEASE) in both trees.

[Thien-Thi Nguyen]

   From: Rob Browning <address@hidden>
   Date: 09 Jul 2001 07:17:17 -0500

   Well, I must admit I don't really see what use the version number is
   here.  If you want to see the recent changes, you can run a cvs diff
   -u -D yesterday -D now (or similar), and if you really want to know
   the version number you can run cvs status.

the version number is not so important as the date (when it comes to a
TODO list).  if the file is to be distributed, knowing clearly what
revision it is helps potential contributors and current developers alike
to avoid wasteful back and forth.  "hey, according to TODO, this needs
to be done, so here's a patch....  oops, sorry i didn't know that was
already done....  drat, these guile developers are so unorganized."

this is why there is an explicit request to preserve revision control
info when passing the TODO around, in the TODO file itself.  we want to
reach out to people w/o requiring CVS access.  for this to work, we need
to also publish TODO on the net regularly (see http://www.glug.org).

   The disadvantage to using keywords (with branches) is that it will
   cause spurious conflicts when you're merging unlesss (as you mention),
   you use -kk, and then you run the risk of corrupting binary files,
   (which we might have if we ever end up byte-compiling or similar).
   Further, people will actually have to remember when they're supposed
   to use -kk.  (Note: see "Branches and Keyword Expansion - Natural
   Enemies" in the info pages for what originally made me think about
   this...)

   I guess to me it just seems like a potential problem with little
   benefit.

the benefit is in communication, which in poor state is arguably the
downfall of every relationship, whether it be between partners or
collaborators.  this means a little more stewardship on our part, but
using tools in a precise way is not a great hardship, IMHO.  we need not
be cvs wizards, but we can be cvs wise through cvs experience.

alternatively, we can always add revision info to the published TODO at
publishing time -- this kind of kludge can be extended lots further, of
course, into a Formal Process. :->

thi