Re: Release?

[Jeff Bailey]

On Fri, Feb 16, 2001 at 01:54:34PM -0500, Alain Magloire wrote:

> > Alain, what's the list of tasks stoping us from releasing inetutils?
> 
> Sorry for the delay, doing grep business.

np =)

> - Backup the patch from Michael Vogth

I can't find the original patchfor this, but it looks like it only 
affects ftpd, so it might be just as easy to keep it.

>   . or rather guarded with WITH_INTERNAL_LS macros or something.

In what case wouldn't you use this?

>   . or better have a real portable internalls (libls) but that is
>     a big effort.

Please define the target platforms for portability.  I can test Hurd.

>   . make this a configure option --whith-internal-ls
> 
> - The r* deamon commands are not working on Solaris(SVR4) because
>   of the use of STREAMS, unfortunately my solaris box was decommission
>   and I do not have root priviledge to any.

How to solve this?  I can make it so that configure won't build r* 
daemons on sun-sparc-solaris* if you'd like.

> - More testing, at least run those utility as the default in a
>   say GNU/Linux environment for a few weeks.

I don't really use any of these utilities (whois, from time to time, but 
I use ncftp, and ssh for everything).

> - whois move to obsolete the one by devnull and use in replacement
>   Marco d'Itri's.  License issues are not clear with Marco's, is this
>   own by FSF ?  Most utilities in inetutils are under BSD which is
>   ok  although there is no major contributions to be under GPL or LGPL
>   if it falls under BSD, seem just fine too.

Marco, have you filled out copyright assignment forms for whois?  Once 
you've confirmed yes, I'll tag the sources and remove whois/

> After finishing with the loose ends with GNU grep and GNU mailutils
> I could take care of business here.  GNU grep has priority because
> some very nasty bugs, and GNU mailutils is also higher in the list.
> If someone wants to take the lead, fine, if not it will have to wait
> a little.

I can take this on, but my only target platforms will be Linux & Hurd.  I 
think perhaps our release goals are otherwise too high with the current 
codebase.  I think our target should be:

[i686-pc-linux-gnu will be used for these tests, due to weaknesses in the 
Hurd's pfinet translator, and machine availability.  Any other platforms 
are then secondary (worth testing if you have it, but not failures are 
not show stoppers)]

o Clients:
 telnet can open a session to a netkit telnetd for 6 hours of constant data 
going through (output of `yes`)
 ftp can open a session to a netkit ftpd and correctly download 500 2-MB 
binary files correctly. (mget *, single directory)
 tftp can open a session to a netkit tftpd and correctly download a 
single file
 rsh can open a session to a netkit telnetd for 6 hours of constant data
going through (output of `yes`)
 rcp can open a session to a netkit ftpd and correctly download 500 2-MB
binary files correctly. (single directory)
 talk can open a session to a netkit talkd for 6 hours
 whois can retrieve the gnu.org record

o Servers:
 telnetd can receive a session from a netkit telnet client and display 6 
hours of constant data going through (output of `yes`)
 talkd can receive a session from a netkit talk client and hold the 
session open for 6 hours
 uucpd will not be tested
 syslogd will not be tested [1]
 rshd can receive a session from a netkit rsh client and display 6 hours 
of constant data going through (output of `yes`)
 inetd will be used to spawn all the inetutils server tests.  It will not 
be tested for load
 ftpd can receive a session from a netkit ftp client and display 6 hours 
of constant data going through (output of `yes`)
 tftpd can receive a session from a netkit tftp client and send a single 
file.

I can run these test on 2 machines at work (That's why the tests are all 
6 hours long).

Interested?

[1] I cannot afford to cripple the logging on my machines.  I beleive 
syslogd to be fully functional because of Hurd testing, anyway.

--
Talk is a trick for taking the mystery out of the world.
 - Seeker, Beyond the fall of night.