Re: next steps for inetutils?

[Alfred M. Szmidt]

   >    * arp tool
   >
   >    * nc (netcat) tool
   >
   > I like these additions, but I am worried about compatibility against
   > the more prolific versions of those tools.

   Agreed, an analysis of existing implementations and their differences
   would be useful.  This applies to some of our other tools too, like
   traceroute where other implementations have slightly different
   behaviour.

Maybe add -T (TCP) to traceroute.

   >    * Fix All warnings with autoconf 2.71 - I didn't want to touch this
   >      before 2.0 since we had succesful build reports, but there are plenty
   >      of old m4 constructs that we should use gnulib tools for instead.
   >
   >    * use gitlog-to-changelog instead of manual ChangeLog entries
   >
   > I'm sorta still against it -- since it would ruin my work flow of
   > being able to edit the ChangeLog file post-factum.  But I am sure I
   > can be convinced without much work ... if someone else does the
   > work. :-)

   Modifying the ChangeLog that ends up in tarballs is possible, see how
   coreutils is doing it.  Many GNU projects appears to be moving this way
   already.

A flat file is going to always be much easier to modify than stringing
together sed expressions.

   >    * Enhance Man pages so they fully supersede NetKit and BSD man
   >    * pages
   >
   > Can you elaboraet a bit?

   There is text in the traditional NetKit/BSD man pages that isn't in our
   man pages.  I am hoping it is at least in our info manual (but I'm not
   sure), and it would be nice to review if there is anything that makes
   sense to put in the man pages.  

Reviewing our documentation is always a good idea.

   * merge ping and ping6 into one binary?  ping6 should mean 'ping -6'.
     There is code duplication between the tools now, and the semantics of
     the tools is slowly diverging.

Maybe not one single binary that depends on argv[0], but functionality
yeah definitly.