[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Badly out-of-date TODO file.
Re: Badly out-of-date TODO file.
Fri, 24 Sep 2010 20:27:57 +0200
* Stefano Lattarini wrote on Fri, Sep 24, 2010 at 02:50:56PM CEST:
> I see that the Automake's "TODO" file is badly out-of-date: the
> dates of the two last real changes (both very small) are 28/03/2007
> and 12/04/2004. Also, it's hard to easily discriminate which parts
> of the file might still be relevant, as the entries lack any sort of
> reference to author, date of writing, or automake version involved
> (yes, I could proably dig those details out by searching the git
> history and the mailing lists' archives, but that's awkward at
That digging is the strategy I'm using, not only for TODO but basically
for all GNU code and documentation that I work on (in various depth, of
It is not easy to get at mailing list contents older than 2001, though.
If somebody has them, it would be nice to send them, suitably gathered,
to gmane.org for inclusion into the archive.
> I think having an up-to-date TODO would be worthwhile and useful.
I have a couple of unpublished patches for TODO. Didn't yet manage to
get all the way through, though, and the patch includes removing at
least one item I'm also not done with yet, and that is writing a section
about parallel make. (That patch has been half-done for months as
For reference, the TODO patch is pasted at the end of this message.
> So, anyone has an idea of how much out-of-date or even misleading
> the current content of TODO is?
Not sure what you mean with misleading. Some parts may be hard to
> Should it be scrapped (apart from
> bits that are clearly and obviously still relevant), and a new
> TODO started from scratch? Or could it be saved somehow?
I definitely wouldn't want to scratch it, even if most of the entries
predate my involvement in Automake.
> Either way, IMHO, there's a lesson for the future to be learned
> here: always add the date (and maybe the version string offered
> by `git describe') to any new TODO entry.
Neither date nor version are really relevant for how outdated a TODO
entry is, though. Some TODO entries might be 10 years old, yet still
Let's put it this way: I'd want to remove entries only if they are
clearly fixed or clearly irrelevant now. Verifying either typically
requires some digging, or extensive digging, for each single entry.
However, in order to improve upon the structure, adding new entries
in a new section, or moving all existing stuff down in some "older
entries" section is probably a good idea.
Generally, and even more with branched development, a single TODO file
is not ideal. A bugzilla would be better, and I'd use the sourceware
GNATS more but it's so lacking in features, and the savannah bug/patch
tracker is, um, not ideal either. Add to that that I'm lazy and try to
do most todo-style management by email folders. Surely not ideal for
collaboration, I'll freely admit. A bug tracker should be usable by
email though, IMHO.
* TODO: Remove entries that have been addressed: unroll loops
in install rules; concept index in the manual, document `make
SHELL="sh -x"' trick, cleanup of source directory. Update
gettext entry, remove reference to FLD, check for directory mode
755 not 777 in distribution.
Update TODO (merge with section on paralell makes)
* TODO: Note on parallel makes done.
diff --git a/TODO b/TODO
index 0c28f49..62f76b0 100644
@@ -212,14 +212,9 @@ might make editing conceptually easier.
* only remove libtool at top level?
-* clean up source directory by moving stuff into subdirs
* consider adding other variables similar to pkglibexecdir?
requests for pkg-dirs with version included
-Avoid loops when installing; instead unroll them in automake
-[ Impossible when @AC_SUBST@ values are used. ]
Some long-term projects:
* if $(FOO) is used somewhere, ensure FOO is defined, either by
user or by automake if possible
@@ -270,7 +265,7 @@ configure.in scripts
From the GNU Standards. These things could be checked, and probably
should be if --gnu.
* Make sure that the directory into which the distribution unpacks (as
-well as any subdirectories) are all world-writable (octal mode 777).
+well as any subdirectories) are not world-writable (octal mode 755).
* Make sure that no file name in the distribution is more than 14
* Don't include any symbolic links in the distribution itself.
@@ -370,7 +365,7 @@ Some things for --strictness=gnits:
Auto-distribute "ChangeLog.[0-9]+"? "ChangeLog.[a-z]+"?
-Internationalize. [ gettext doesn't have the necessary machinery yet ]
+Internationalize. [ gettext has the necessary machinery since 0.13 ]
am_error should use printf-style arguments (for eventual gettext scheme)
François says the ordering of files in a distribution should be as follows:
@@ -449,15 +444,11 @@ include Greg Woods' more sophisticated "cvs-dist" target.
must document the targets required for integration with
-document the "make SHELL='/bin/sh -x'" trick for debugging
-section on relationship to GNU make. include notes on parallel makes
-add a concept index
+section on relationship to GNU make.
move discussion of cygwin32, etags, mkid under other gnu tools
-CCLD, CXXLD, FLD
+CCLD, CXXLD, ...
@@ -561,7 +552,7 @@ that aren't mentioned?
* copyright notice
Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
-2007 Free Software Foundation, Inc.
+2007, 2010 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by