rev. 1/19/96

-To: watchmakers95@MIT.EDU
-Cc: watchmakers@MIT.EDU, dcns-dev@MIT.EDU
-Subject: List of Zone Residents, IAP Work Ideas
-Date: Thu, 11 Jan 1996 17:08:17 EST

You should set yourself a schedule, with specific pieces you expect to
accomplish each week (or more often).  You can have your partners in
crime go over the schedule, you can ask me to look at it, and you can
certainly adjust as you find that creating the world takes a little
more than an afternoon, but it is helpful to set such a schedule.

My belief is that the pc, mac, and kerberos folks know what they are
working on.  That just leaves the UNIX people hanging.

Please report accomplishments to milestones@mit.edu

and have fun!  it's IAP, after all.

IAP UROP Type Projects

1.  neos servers port to solaris
2.  version server port to solaris (jyp investigating)
3.  discuss server port to solaris
4.  review bugtracking packages
5.  build netprob for SGI (cat investigating)
6.  check other lockers--see if they have SGI versions--if not, consider building

For those who may not know- I maintain a list of "significant Athena software
packages" in file what_runs_where at the top level of the info locker- you
can use it to quickly check on what's there now. Note that it does not cover
everything that might be out there - it's oriented towards end-users and 
may miss lockers that contain developer tools and things mostly of interest
to staff. And give me a holler if a) you find something wrong or b) feel
that I'm missing something that ought to be there (given the end-user focus).

                                        Alexp

7.  check other lockers--see if they have Sol 2.4 versions--if not,
    consider checking operation and rebuilding where needed
8.  pick an athena source package.
	build it.
	study the sources.
	document the following four scenarios

	a.  a bug has been reported--what does someone need to know to
	    find and fix?
	b.  we are moving the package to a new OS--what do you need to know?
	c.  we are implementing an enhancement--what do we need to know?
	d.  what changes, improvements, etc. do you recommend for future planning?

	consider architecture diagrams, protocol specs, and other documentation--
	suppose you came back to the package in a year and had to quickly get
	familiar again, what do you need?

9. Figure out TRACK--why does it thrash?

10. investigate and if necessary implement library/daemon/etc. for
    simple network time protocol

11.  There's always bugs in netprob to do...

12.  Or you could dig through suggest and the olc logs and see what's there...

13.  kerberized lpc (see matt)

14.  kerberized lert admin tools