plan for A-A-P 1.0
			      ------------------

     Author: Bram Moolenaar
Last Change: 2002 April 2


INTRO

This plan is the roadmap to get to the first release of A-A-P.

Main milestones:
version 0.1: proof of concept
version 1.0: first fully working version

After version 1.0 comes continued expansion.

For background information about A-A-P, functionality, the current design
sketch and design decisions see the web site: http://a-a-p.org.


VERSIONS

Main goal for version 0.1 is to define the recipe syntax and do a proof of
concept with this.  This means that all parts that interact with recipes must
be (partly) implemented to check if the interaction works well.  Most of the
functionality not dealing with recipes will be missing.  There will be known
bugs.  The design will be at a level such that after version 0.1 several
people can work on modules in parallel.

Version 1.0 will be a working system.  It will not include all features, it's
good enough to get people interested in using it and is an invitation to help
enhancing it.  All versions after it should be backwards compatible.  This
means the interfaces and file formats must be very stable and fully tested.
So long as it's not certain that the design choices are right, version 1.0 is
not ready.  The goal is not to include as many features as possible, but to
create a rock solid base for further growth.


PEOPLE

For version 0.1 the project leader will try to find a few others to help
implementing parts of A-A-P and to help defining and reviewing the modules and
interfaces.  Working with a small group will avoid wasting too much time on
vague discussions.  The danger with the architecture is that it gets stuck in
too many alternatives.  A group of about five people who work weekends on
A-A-P should be sufficient.

For version 1.0 various people are expected to join in and implement parts of
A-A-P.  The project leader will implement the rest and overview the total.
Some form of stimulation will be required to get people interested in
implementing parts of A-A-P (more than a T-shirt and less than a salary).  The
work needs to be split up in small pieces, because one can't expect volunteers
to have much time available.  A rough estimate is that ten active developers
are needed, plus ten people who try out A-A-P and provide feedback.

If the project is successful it will continue to be developed.  After version
1.0 the project will grow big, with a core group of developers and many people
who contribute specific items.


WORK PACKAGES
=============

The work is split up in packages.  For each work package is mentioned what
should be done for version 0.1, for version 1.0 and what is postponed until
later.  The explanation makes clear what is contained in the package and gives
an estimate of how much work it is.

Included in each work package:
- Quality control: automatic checks and tests.
- Messages in English, translation possible.
- Release as often as possible.

Only the time for version 0.1 is included here. "PL" stands for Project
Leader.


DESIGN

In this work package:
- Define the modules of A-A-P and the work packages, both functionality and
  implementation.
- Define the interfaces between the modules.
- Extend and update the list of design decisions.
- Make the overall implementation choices (e.g., the languages and libraries
  used).

for version 0.1: Fully worked out
for version 1.0: Minor redesign and small enhancements
	  later: Small enhancements

Excluded here is design of a module itself, that is included in the work
package for the module.
For version 0.1 most of the interfacing is done through the recipe format and
implemented by the recipe executive, thus part of the work is done in those
work packages.

Time for version 0.1: 2 weeks (PL)


RECIPE SYNTAX

In this work package:
- Consider alternatives, compare how well the functionality works in each and
  how simple the format can be learned.
- How to use recipes for defaults/preferences (user, system, project).
- Check the interaction between each module and recipes, e.g., How to use
  recipes for a project in the IDE and how to use recipes for automatically
  generated dependencies.
- Write good documentation with examples.

for version 0.1: Mostly defined, but no user documentation
for version 1.0: Fully worked out, documented and tested
	  later: Further enhancements

Since the recipe format is very important and it forms the interface between
many modules, it will take quite a bit of time to make the right choices.
Some of the work (making test implementations) is in the "recipe executive"
work package.

Time for version 0.1: 3 weeks (PL)


RECIPE EXECUTIVE

This implements the "recipe executive" module of the design.

for version 0.1: Most things working (proof of concept for the recipe format),
		 but non-essential functionality missing and only one or two
		 ways to do something (e.g., only one kind of signature, one
		 editor supported).
for version 1.0: Fully working, except a few things.
	  later: Implement further enhancements of recipes.

This is the largest module of the design.  The basics should not be difficult,
but some extra time is needed for redoing parts while the recipe format is
being developed.

Time for version 0.1: 6 weeks (PL)


RECIPE FINDER

This is for locating recipes that can be used with the "recipe executive".

for version 0.1: Nothing, download recipes manually
for version 1.0: Web based system for volunteers to submit recipes, use of
		 existing systems (e.g., FreeBSD ports)
	  later: More advanced system?

This can be done later, because there is not much interaction with the rest.

Time for version 0.1: nothing


DEPENDENCY CHECKER

This implements the "dependency checker" module of the design.

for version 0.1: Hacked up version for one language, interaction with recipes
		 working
for version 1.0: Fully working for a few languages
	  later: More languages

Most work for version 0.1 is to decide how the interaction with recipes works.
Otherwise it's part of the "recipe syntax" work package.
Making this work for C should be simple, existing commands can be used.

Time for version 0.1: 1 week (PL)
Optionally a volunteer may make it work for other languages.


CROSS REFERENCER

This implements the "cross referencer" module of the design.

for version 0.1: First database format, working for a couple of languages,
		 interaction with recipes working
for version 1.0: Database format fully defined, working for several languages
	  later: More languages

Most important is to define the format for database files that contain the
information.  For version 0.1 a first idea should be implemented to check that
the interaction with other modules works.  After version 0.1 the format will
be changed, but at version 1.0 it must be fixed.

Time for version 0.1: 4 weeks (volunteer)


VERSION CONTROL WRAPPER

This implements the "version control wrapper" module of the design.

for version 0.1: Hacked up version, interaction with recipes working
for version 1.0: Most important things working with just a few VCS; Suggest a
		 VCS to use for new projects.
	  later: More features and VCS supported

For version 0.1 an implementation with one VCS should be made, so that the
recipe format can be checked.  Existing applications (e.g., cvsup) can be used
as an example.

Time for version 0.1: 2 weeks (PL)


PERSONAL VERSION CONTROL

This implements the "personal version control" module of the design.

for version 0.1: Nothing (for an update apply all patches again)
for version 1.0: Only keep track of applied patches applied by the recipe
		 executive
	  later: First version

Although this is very useful, without this module most things work.  Thus it
can be postponed until later.  Although there is a small risc that something
needs to be added to the recipe format once this gets implemented.

Time for version 0.1: nothing
Optionally a volunteer could start working on this.


ISSUE TRACKER WRAPPER

This implements the "isssue tracker wrapper" module of the design.

for version 0.1: Hacked up version, works with recipe
for version 1.0: Working for a few issue trackers
	  later: Working with more issue trackers

For version 0.1 the only thing needed is how this module interacts with the
recipe format, which should not be very difficult.

Time for version 0.1: 1 week (PL)


GUI IDE

This implements the "GUI IDE" module of the design.

for version 0.1: Hacked up version based on an existing IDE; can use a recipe
		 as a project file
for version 1.0: Working but minimal on features, main interfaces defined,
			have at least one tool available for each purpose.
	  later: Many feature enhancements

This is almost a project by itself, but fortunately most of this can be
postponed until after version 0.1.  Using the recipe as a project file should
be given some testing.  Starting with an existing IDE is required, starting
from scratch would be too much work.  IDLE can be used, perhaps there is
something that is even better.
The required time will greatly depend on how much effort is invested in making
a good UI.  For version 0.1 this is not needed.

Time for version 0.1: 4 weeks (volunteer)


CONSOLE IDE

This implements the "console IDE" module of the design.

for version 0.1: Nothing
for version 1.0: Nothing
	  later: First version

All issues concerning recipes are covered by the GUI IDE.  Providing IDE
functionality in a console can be postponed until after version 1.0.

Time for version 0.1: nothing


AUTOMATIC CONFIGURER

This implements the "automatic configurer" module of the design.

for version 0.1: Nothing
for version 1.0: Nothing
	  later: First version

The interface with recipes is unlikely to be different from using autoconf
(shell script), thus this can be postponed until after version 1.0.

Time for version 0.1: nothing


WEB SITE

The web site provides information about A-A-P to users:
- The current status of the A-A-P project; news items.
- User documentation.
- Store for recipes (like Vim scripts on Vim-online).

It allows developers to exchange ideas and results:
- Maillist archive.
- Version control system with latest versions and patches.

for version 0.1: Provide up-to-date info on the project, setup maillist and
		 code distribution
for version 1.0: Add system to allow anybody to upload recipes and others to
		 search for recipes
	  later: Regular updates

Excluded here is writing documentation about the various modules, that is
included in each work package.

Time for version 0.1: 1 week (PL)


USER DOCUMENTATION

In this work package:
- basic documentation included with A-A-P
- other parts downloadable or available on the internet

for version 0.1: Only a few things
for version 1.0: Complete documentation and examples
	  later: Updates following the development

Excluded here is describing the recipe format, that is in the "recipe syntax"
work package.

Time for version 0.1: 1 week (PL)
Optionally volunteers may add documentation.


PROJECT MANAGEMENT

In this work package:
- Promoting A-A-P around the world.
- Invite authors of related tools to work together with A-A-P.
- Facilitate communication between A-A-P developers (maillist, newsgroup).
- Maintain listing of tools that can be used with A-A-P and how well they work.
- Make further plans.

for version 0.1: Invite a few people to join
for version 1.0: Make it attractive for people to join
	  later: Continue managing the project

Time for version 0.1: 3 weeks (PL)


PLANNING
========

Total time for Project Leader in weeks for version 0.1:
DESIGN			2
RECIPE SYNTAX		3
RECIPE EXECUTIVE	6
DEPENDENCY CHECKER	1
VERSION CONTROL WRAPPER	2
ISSUE TRACKER WRAPPER	1
WEB SITE		1
USER DOCUMENTATION	1
PROJECT MANAGEMENT	3 	total:  20

Volunteers needed:
CROSS REFERENCER	4
GUI IDE			4

This results in a development time of about five months.  Starting halfway
April, version 0.1 should be available halfway September 2002.

It is very difficult to place a milestone before version 0.1, because
designing the recipe format requires doing a bit of everything, without a
specific sequence that can be decided upon now.  Defining something like "50%
of the work is done" is the best that can be done.

Progress can be tracked by estimating how well the recipe format is defined.
The more stable it is, the more progress has been made.  Therefore a monthly
evaluation will be done about how well the recipe format has been defined.
This can be expressed in:
- How much of the requirements has been taken into account.
- How many of the modules using the recipe have an (experimental)
  implementation or design that show exactly how they use the recipe.
- How much of the recipe format has been tested for real use.