Subject: Ideas and Request for Participation in Open Development

From: Kent Landfield <[email-masked]>
Date: Mon, 11 May 1998 09:49:05 -0500 (CDT)

Dusting it off.... ;)

Background:
-----------

For quite a few years there has been a rather stable FTP protocol
specification.  In the past few years a great deal of work has gone
into creating an FTP server that provided functionality beyond just 
the FTP protocol.  The result was the WU-FTPD server.  The WU-FTPD 
server was initially developed under a grant funded by the National 
Science Foundation.  It has since taken on a life of its own and has 
been reported by one FTP software vendor to be the number one ftpd 
server on the Internet fielded at over 60% of the sites offering 
anonymous ftp.

There are currently multiple efforts to:
	- extend the base FTP protocol,
	- to integrate new means of access authentication,
	- to add the features needed to effectively administer 
	  an FTP server in today's Internet.  

These efforts seem to be going in different directions. There has 
been no attempt to produce a unified FTP Server that is capable of 
satisfying the needs of these currently divergent projects.

Current efforts underway consist of:
	WU-FTPD
	RFC 2228 work
	Kerberos base FTP/FTPD
	IETF FTPEXT Working Group
	Virtual Hosted FTPD
	Vendor FTPD Extensions
	FTP Security tunneling
	Server Performance Enhancements
	Server Administration Tool Development

In order to continue the evolution of the WU-FTPD server functionality,
it is important that it keep up with the advancements in the protocol 
as well as the features needed to manage ftp services in our changing 
networked environments.

This is a request for participation in an effort to create the next
generation of WU-FTPD enhancements.  The purpose of the project is 
to integrate new capabilities requested by the Internet community as 
well as the ongoing work of the IETF FTPEXT working group and other 
FTP related development efforts. This effort is being established 
using basically the same model that is used for the Apache web server 
development.  What follows are general thoughts on how we can get this 
set up effectively.  This is just an initial stab at it so everything 
here is fair game at present.  This was patterned after (and some 
words taken from) the Apache project management documentation. While 
this model is not perfect, it is a starting point for discussion and 
it is expected we will tailor it to suit our needs.

Core membership:
----------------

There will be a team of core developers. These people will be given 
logins and access on a central developmental system.

Access to the project baseline:
-------------------------------

Developmental access to the baseline will accomplished be via CVS. 
This is to be used to make it easier to apply and track patches. The 
project's current software base, documentation, and information files 
are to be held in CVS repositories. Core developers will be able to 
check out a copy of the repository, in essence replicating it on their 
own machines. The developers can change files and test as needed, and 
selectively commit those changes back to the central repository using 
a single CVS command. A change to the repository triggers an e-mail 
message describing the change. This message is then sent to a separate 
mailing list. Other developers can then use a CVS command that searches 
for modifications to the remote repository and merges them into the copy 
on their machine.

To assure that we do not have problems with security, it is proposed 
that SSH be used so developers do not need to send their passwords in 
the clear over the Internet.  SSH client software will need to be 
installed on all development systems in order to allow transparent 
execution of remote CVS commands or logins on the project server.  
SSH will also automatically encrypt all traffic as well.

Mailing lists: 
---------------

There will be a few mailing lists needed to support the project.  

First there will be a core developer list. This will be the primary 
means of communication for active developers.  Subscription to the 
developer's mailing list will be open to the public.

Topics will include designs for new features, bug fixes, user problems, 
important news about the ftp community, product release dates, and 
project strategy etc.  Private e-mail will be used for resolving 
localized conflicts between group members, or when the discussion 
includes confidential information. 

All list traffic will be archived in Unix mailbox format and using a 
modified hypermail with search capabilities so that all can see what 
has been said when they need to or have time to.

The second list will be a public announcement-only list that anyone 
can subscribe to so that people can be alerted to important project 
progress, patches or new releases.

The third list will be a change announcement list where CVS change
notifications (described above) will be sent. Subscription to this 
list is closed to the general public, only core members (or the CVS 
system) may post.  Redistribution of traffic on this list is 
discouraged.

The fourth list will be a private announcement list notifying 
interested core members of all postings to the problem tracking 
system. An archive of submitted problem reports will be publically 
available.

Problem Tracking:
-----------------

We need a way to track unsolved problems. To do this we need a 
central problem-tracking system that is accessible via both Web 
and e-mail.  Initially it is envisioned that GNATS (the Gnu Problem 
Report Management System developed by Cygnus) will be used.  There 
others, for example another system is called PTS (Project Tracking 
System) that embeds directly into an Apache server and uses a back-end 
database system for all transactions.  This may be something for us 
to consider using as well. 

Voting:
-------

There is no project CEO, president, manager, or even secretary. 

People volunteer for needed tasks and rotate tasks when they get 
tired or are too busy to continue. 

Decisions are to be made by consensus (for code changes or legal 
issues) or by majority vote, with the voting taking place via the 
core developers mailing list.  Core developers are the only people 
who have a vote. Serious decisions  such as release readiness and
leagal issues requires input from all of the active members.

To be committed on the baseline system's CVS tree, at least three 
positive votes are required and there can be no negative (or veto) 
votes.

Adding Members:
---------------

New members of the core group will be added when a frequent contributor 
is nominated by one core member and approved by a simple majority of the 
core members.  In most cases, this "new" member should have been actively 
contributing to the group's work for some period of time. 

Developer Community:
--------------------

It is the intention of the project to foster continued development 
of a full functioned ftpd and to assure that all suggestions are 
heard and responded to.  It is expected that there will be suggestions, 
enhancements and fixes coming from the Internet community.  It is 
our intention to try to respond to the needs of a changing network 
environment.

Source Archives:
----------------

There are two different baselines here, the developmental one using 
CVS and the public version.  The public version will be available via 
ftp, http and anonymous CVS and will be mirrored in various places around 
the net.

The CVS tree will be publicly available for read-only access to foster 
the development efforts of new participants in the project.

Initial areas of work:
----------------------

Before we can write a line of code we need to accomplish a few things.
First is to establish the core developer team.  Second we need to get
a system setup to act as the central repository, mail hub and web site
for the project.  The CVS repository needs to be created and the core
developer accounts need to be established.  Core developers will need
to assure ssh client software is setup on their systems.  We will then 
need to develop the working guidelines of the project that all can agree 
on. (Note: the above is a think piece to get us started.)

The above is needed from an administrative perspective simply to get 
the project started.  At that point we need to

   * Review of the current wu-ftpd code structure with suggestions 
     as to its reorganization to support modular additions,

   * Document an API to allow easily added feature modules,

   * Examine of the feature set of emerging functionality to be added,

   * Determine which features should be developed in parallel or in 
     sequence and in what general order,

   * Start working on it.

This will require that the project track the work of the various FTP
related development efforts that are occurring, most notably the IETF
FTPEXT working group.

Summary:
---------

If you would like to participate as a member of the project, or 
if you would like to recommend another person as a prospective member, 
please let me know. If you have questions don't hesitate to ask.  

Thanks.

-- 
Kent Landfield                        Phone: 1-817-545-2502             
Email: [email-masked]             http://www.landfield.com/
Email: [email-masked]                   http://www.nfr.net/
Please send comp.sources.misc related mail to [email-masked]
Search the Usenet Hypertext FAQ Archive at http://www.faqs.org/faqs/