bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-inetutils] Present release goals


From: Mats Erik Andersson
Subject: [bug-inetutils] Present release goals
Date: Wed, 12 Oct 2011 19:44:36 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Dear all,

I put this into a fresh thread in order that Mutt and all
other email archive refrain claiming old context!


I think we can agree that the present upgrades to and the present
content of our source tree, propells more than one utility to a
state that most users would name as contemporary.

Thus I propose we only do the last polishing for a release
in a close future, followed by a small set of new goals for
a next release, which could take place fairly rapidly, still
calling it a major release.

The issues we need to attend to for the immediate release are:

   * The revision of the autoconf/automake settings
     must be completed. Presently the work in June
     broke the functionality for OpenBSD. (There is
     a "struct option" that leads to a failure.

     The acceptance test for this step is that
     a bootstrapped source tree must be movable
     via "rsync -CLa from/ host:/to/" to all of
     GNU/Linux, GNU/kFreeBSD, FreeBSD, and OpenBSD,
     and be configurable and compilable without
     errors. These are the four systems we can
     claim support for!

   * The problem with rpl_ioctl() and GNUlib for
     GNU/kFreeBSD [1] must be resolved. It is beyond
     my understanding why Simon is not attending to
     this problem, be it that he prefers GNU/Hurd.

   * tftpd failing for IPv4-mapped-to-IPv6 [2].
     (Ignore for the time being problems in OpenSolaris.)
     The solution must be checked on GNU/Linux,
     GNU/kFreeBSD, and FreeBSD, with a dual stacked
     superserver and "bindv6only=0".

   * I have prepared a recalculated for the TFTP client,
     which got delayd as I discovered the preceding error.
     Should we include this?

   * The test script for syslogd [3] must be adapted
     to automated testing. The script has been used
     manually by me, and all its features were instrumental
     to me in uncovering segfaults and verification of new
     code additions. It is best that someone else makes the
     adaptions to automatic testing.

   * The problems claimed in "tests/tftd.sh" on the build
     engine Hydra of NixOS should probably be ignored.
     The mail conversations showed that their setup does
     not even include "/etc/services" in the right location,
     so they are severely breaking every sane rule of thumb.

   * Update "doc/inetutils.texi".

   * Write NEWS.

   * Test the utils again and again!

   [1] http://lists.gnu.org/archive/html/bug-inetutils/2011-09/msg00055.html
   [2] http://lists.gnu.org/archive/html/bug-inetutils/2011-09/msg00002.html
   [3] http://lists.gnu.org/archive/html/bug-inetutils/2011-08/msg00003.html


Next release
============

I believe these are sufficient to arrive at a worthy update.

   * Implement IPv6 support in "ftpd". At the moment I have done
     this in a preliminary patch set, which runs as expected on
     OpenBSD. Should the "EPSV ALL" be implemented, there is an
     old bug in the FTP client that must be attended to also.
     That malfunction is present in "netkit-ftp" in Debian,
     in "ftp" of OpenBSD, and "ftp" of FreeBSD, i.e., in all
     descendants of Netkit, so there is no reason for panic.

   * Support OpenSolaris. Besides iruserok() [4], the main
     obstacle for OpenSolaris is the Kerberos code. There
     is also a known problem in "libinetutils/tftpsubs.c",
     which must be debugged properly.

   * Rework Kerberos support, separating Kerberos4 code
     from KerberosV code, and make proper implementation
     of Shishi code that works on all platforms we want
     to support.

With these accomplished, I claim that GNU Inetutils would
be a strong competitive set of services. The reviewing of
Kerberos code alone merits a new release in my opinion.

   [4] http://lists.gnu.org/archive/html/bug-inetutils/2011-08/msg00007.html


The discussion may commence!

Regards,
  Mats



reply via email to

[Prev in Thread] Current Thread [Next in Thread]