TODO

   1 * get account on fencepost.gnu.org (email accounts@gnu.org)
   2   set up copyright papers?
   3   'assign.future' and 'request-assign.future.manual'
   4
   5 * Update stow.texi
   6   - The email address in 'Reporting Bugs' needs to be updated
   7
   8 * Figure out what needs the optin 'nostow' 'notstowed'. Can they be removed?
   9
  10 * _texi2man_ needs author/copyright/license to be completed
  11
  12 * Update http://directory.fsf.org/project/stow/
  13
  14 * Update savanaugh CVS
  15
  16 * Check that all email addresses are working: need an account on fenchpost for
  17   this bug-stow@gnu.org, help-stow@gnu.org
  18
  19 * Get some pre-testers: need to find appropriate mailing list?
  20
  21 * Announce release on info-gnu@gnu.org.
  22
  23 * Autodetect "foreign" stow directories
  24
  25 From e-mail with meyering@na-net.ornl.gov:
  26
  27     > My /usr/local/info equivalent is a symlink to /share/info
  28     > because I want installs on all systems to put info files in that
  29     > directory.  With that set-up, stow chokes on fact that
  30     > /usr/local/info is a symlink.
  31
  32     [...] Stow is designed to be paranoid about modifying anything it
  33     doesn't "own."  If it finds a symlink in the target tree (e.g.,
  34     /usr/local/info) which doesn't point into the stow tree, its
  35     paranoid response is to leave it the hell alone.  But I can see in
  36     this case how traversing the link and populating the directory on
  37     the far end would be OK.  Question: is that a special
  38     circumstance, or would it always be OK to populate the far end of
  39     a symlink in the target tree (when the symlink points to a
  40     directory in a context where a directory is needed)?  And: if it's
  41     a special circumstance requiring a command-line option, should the
  42     option be a mere boolean (such as, "--traverse-target-links") or
  43     should it be an enumeration of which links are OK to traverse
  44     (such as, "--traversable='info man doc'")?
  45
  46 Does Version 2 fix this? (Kal)
  47 I think that because it never needs to create /usr/local/info,
  48 it only needs to check th ownership of links that it _operatates_ on,
  49 not on all the elements of the path.