\section{How to Contribute Software to the Yohkoh System}

We encourage users to contribute SW to the system, however we strongly
recommend that people at remote sites do not make changes or additions
to the directories under \$ys.  If additions must be made, we recommend
that they be placed in the \$ys/site/soft branch of the Yohkoh software tree.
Software in the \$ys/site/soft branch are not changed during software
installations and upgrades.
The routines placed in the \$ys/site/soft branch should not be modified
versions of ``official'' routines since updates to those routines will
not be accessed.
\index{site software}\index{contributing software}\index{local software}\index{local software contributions}
See the discussion of IDL\_PATH to understand how you can have both
Yohkoh Software directories and personal directories accessible at the
same time.

We have a system in
place to facilitate contributions via anonymous FTP from remote systems. 
A set of Unix script files is used to automate the transfer (all FTP
commands are handled within the scripts) and to help the Yohkoh SW
managers to handle the contributions in a systematic fashion
\footnote{The method used in the past was to use the {\it online} script.
We request that people start to use the {\it ys\_contrib} script
as the {\it online} script will be removed at some point in the future.}.

There are several categories of user contributions which we are interested
in having remote sites submit to the system:

\begin{enumerate}
\item Software: Software contributions are expected to follow the guidelines described
in appendix of the Reference Guide.

	\IItem
	\item Corrections to distributed Yohkoh SW. This category would include any
	changes which were required at a remote site to fix a known problem (bug)
	with a distributed routine.  It also includes modifications which were
	required to get the routine to work properly at the particular site 
	due to differences in environment (operating system, shell environment, etc)
	
	\item Enhancements to distributed SW. This includes any changes made at remote
	sites to add new functions or features and thought to be of
	a more general interest.

	\item New software which would be of use to others and possibly avoid duplication
	of SW effort.  General purpose tools and utilities
	\end{itemize}

\item Non-Software:
	\IItem
	\item Non-SW information of general interest. Examples would be hints, clever 
	   tricks and mistakes encountered during the use of the Yohkoh SW system.
	   As these might get automatically included in a newsletter without editing, 
	   please keep these  brief and to the point.
	\end{itemize}
\end{enumerate}

Submissions may be made through the use of the one line command
\footnote{Requires Yohkoh SW Version 931108.02 or higher}:
%
\ultrixinputa{ys\_contrib  files [README] [/ysmod]}

\begin{verbatim}
   Where: files   = SW source, tar or compressed tar file
          README  = optional special announcement or description (file) 
          /ysmod  = flag modifications to existing/distributed Yohkoh SW
\end{verbatim}

Some examples are:
%
\ultrixinputa{ys\_contrib stepper.pro /ysmod}
\ultrixinputb{ys\_contrib spec\_fitter.pro spec\_filter2.pro}
\ultrixinputb{ys\_contrib HINTS}
\ultrixinputb{ys\_contrib local\_lib.tar}
%
On remote machines, this command (Unix alias) will execute a set of script files which
\IItem
\item connects to anonymous FTP account on the master host
\item create subdirectory pub/swmaint/contrib/{\it node}/{\it user}
\item ``FTP puts'' the remote files
\item sends mail to software account and {\it user}@{\it node} announcing new contribution
\end{itemize}

On ISAS local machines, it checks to see if the person has a /ys/ucon/soft
directory and copies it there if it exists.  If not, it follows the steps
shown above for remote machines.

A cron job running on the SW master will monitor the activity of the user 
contribution area. It would perform any decompression and tar extraction 
required (.Z and .tar files) and sends mail to the Yohkoh SW managers 
if contributions sit around too long without access.  Possible disposition 
of contributed items include:
\IItem
\item move to \$ys (atest or ucon) area as appropriate
\item delegate review and modification, then mv to \$ys
\item reject/delete
\item e-mail to {\it user}@{\it node} notifying
\end{itemize}

Contributed File Name Conventions - the following restrictions apply.

\begin{verbatim}
File Type               Required Name

tar                     <name>.tar
compressed              <name>.Z
compressed-tar          <name>.tar.Z
idl source code         <routine>.pro 
\end{verbatim}

If $<$routine$>$ is a correction or an enhancement of an existing routine,
then the file name must be identical to the existing routine which it
corrects or modifies.  If filename is HINTS, it is assumed to be
``non-software'' and may get included in newsletter verbatim. 

