Re: Badly out-of-date TODO file.

[Stefano Lattarini]

Hi Ralf.

This isn't an urgent matter (in fact, second-guessing, I'd now adress 
the message to address@hidden rather than to address@hidden),
so here are just a couple of thoughts...

On Friday 24 September 2010, Ralf Wildenhues wrote:
> Hi Stefano,
> 
> * 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 best).
> 
> 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 course).
> 
> 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.
> 
> Sure.
> 
> 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 well.)
> 
> 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
> understand, sure.
Also, some parts might refer to things that might have been seen
as useful once, but that would now (after years of code and API 
developement, and maybe even policy changes) be impossible or
counter-productive to implement.

> > 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 relevant.
True; but the "date & version" wasn't a panacea, rather just a
small help.  But your comments suggests that it could have been
just "wishful thinking", after all :-(
 
> 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.
Yes.  Oh well, fixing  just an entry at time might be feasible and
useful anyway.
 
> 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.
True.
> A bugzilla would be better,
I've never used one.  I guess it would be a good time to start :-)

> 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.
True.

> A bug tracker should be usable by email though, IMHO.
I heartily agree.

For what concerns patches for TODO, let's leave them for another time
(there's already a too much large queue waiting).

Regards,
  Stefano