plan for A-A-P 1.0
third edition
------------------
Author: Bram Moolenaar
Last Change: 2003 January 17
INTRO
This plan is the third version of the roadmap to get to the first release of
A-A-P. The experience from the first half year of the project has been used
to adjust the plan for the remaining work.
Main milestones:
version 0.1: proof of concept
version 1.0: first fully working version
After version 1.0 comes continued expansion.
The milestone for version 0.1 has been reached. This plan is about getting
from version 0.1 to 1.0.
For background information about A-A-P, functionality, the design and design
decisions see the web site: http://A-A-P.org.
VERSIONS
The main goal for version 0.1 was to define the recipe syntax and do a proof of
concept with this. This means that all parts that interact with recipes had
to be (partly) implemented to check if the interaction works well. Most of
the functionality not dealing with recipes is missing. There are known bugs.
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.
This plan is being written when version 0.1 has just been released. The
"proof of concept" can be considered to be successful: The essential
functionality has been implemented and the recipe format is stable. Examples
have been made and are working properly.
The work in this plan is for version 1.0 and 1.1. Version 1.0 will be the
first release that includes all the intended functionality. After that we
anticipate to receive remarks and some things need to be completed. Thus
version 1.1 will contain only a bit more functionality.
WHAT HAS BEEN LEARNED
All the work for version 0.1 was done by the project leader. Originally two
work packages were planned to be done by others: The GUI IDE and the cross
referencer. Unfortunately, no volunteers could be found for this work. The
work was reduced to only figure out the interfaces with the recipe format.
The rest was postponed until after version 0.1.
The main reason potential volunteers decided against working on an A-A-P
package was lack of time. This, of course, is also a matter of priority.
Apparently other things were more interesting to spend time on (that includes
studies and family). For this plan four methods will be used to deal with
the lack of volunteers:
1. Split the work for volunteers in smaller parts. Deciding to work on
something for a few days is a lot easier than committing to several weeks
of work. And once those few days have been invested, it is easier to work
for a few more days.
2. Make the work more attractive. For the intended audience this means it
must be useful for themselves. The presentation of the work to be done
should make clear why it is useful for a volunteer.
3. The important work is not planned to be done by volunteers, because we can
not rely on a volunteer being available.
4. Intentionally omit or postpone features that are interesting and could be
done by a volunteer. These features will be attractive for someone to add.
This can only be done for non-essential features.
For some work specific groups of people could be attracted to work on A-A-P by
making sure the results are useful for them. For example, Vim users are
interested in interfacing the editor with a debugger and cross referencer.
Selecting Vim for making the first GUI IDE interfaces will increase the chance
a few Vim users will volunteer to help implementing this.
The split up in work packages as it was done for version 0.1 has worked very
well and the planned work for the project leader was mostly done in the
estimated time. Therefore the split up in packages does not need to be
changed and the estimation of required time will continue in the same way.
WORK PACKAGES
=============
The work is split up in packages. For each work package is mentioned what
should be done 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.
The Design package is no longer present, since most of the overall design has
been done and it appears to be stable. Each package includes the design
required for it (including interfacing with other modules).
A new work package is "examples". This was added to impove the promotion of
A-A-P. Otherwise the work would be focused too much on technical issues.
"PL" stands for Project Leader.
RECIPE SYNTAX
Most of the recipe syntax has already been defined. For version 1.0 the
remaining work is:
- Improving the ease of use.
- Improving the consistency of commands.
- Detailed documentation of the syntax and semantics.
Not included here is adding recipe items specifically for a work package.
The "recipe executive" package is closely related.
For version 1.0 the recipe syntax must be stable, thus no work is planned for
version 1.1.
Time for version 1.0: 2 weeks (PL)
Time for version 1.1: -
RECIPE EXECUTIVE
This implements the "recipe executive" module of the design. This is the
"aap" program. Most of this was already done in version 0.1. Remaining for
version 1.0 is:
- Lots of testing. Python is very permissive, hardly any error is detected by
the compiler. And the program must be very reliable, existing features must
keep on working when more code is added. Part of this is planned to be done
by volunteers.
- Implementing a few more generic commands and extending existing commands.
The examples in the documentation should all be working.
- Add more actions (e.g., support for compiling more languages). Can mostly
be taken from SCons. This should be done by volunteers.
- Make it work on MS-Windows. Only a few problems are expected, since Python
is portable. Support at least one C compiler (e.g., Borland 5.5).
- Fix reported bugs.
This is the largest module of the design. The time for version 0.1 was
underestimated. Therefore the time planned here is more than wat might be
expected.
For version 1.1 some more bug fixing is expected to be required.
Time for version 1.0: 3 weeks (PL) 3 weeks (volunteers)
Time for version 1.1: 1 week (PL)
PORT RECIPE
This work package includes the work on recipes specifically done for port
recipes. In version 0.1 only the basic work was done. Implementation needs
to continue to be able to handle porting more applications and to support more
systems.
The response on the paper presented at the European BSD conference 2002 was
positive, but after that not much happened. There does not appear to be
enough enthousiasm to give the work on the port recipe priority over other
work packages.
Further work on the port recipe will be postponed until after version 1.0.
If some people find the port recipe useful, they could pick up the work
earlier.
Time for version 1.0: 6 weeks (volunteers)
Time for version 1.1: -
RECIPE FINDER
This is about locating recipes that can be used with the "recipe executive".
Recipes can be found on the system, on a local network and on the internet.
They are used for ports (installing from source code) and getting an
executable for generic tools for a specific system, such as "unzip".
The work includes:
- Designing the system to search in several places, partly depending on the
system (e.g., for FreeBSD search for ports on the FreeBSD web site). Decide
how the user can specify what locations are to be searched.
- Setting up a web site where everybody can upload recipes. The Vim-online
site can function as an example.
- A system for the recipe executive to search the web site for a specific
recipe.
- Making a few recipes for tools required by A-A-P itself and examples, e.g.,
unzip and scp.
For version 1.0 a first implementation should be ready. For version 1.1
requests from users are to be expected, both bug fixes and extending the
functionality will need to be done.
There is hardly interaction between this work package and others, therefore
the work can be reduced without hurting the release too much. When running
out of time this package may be reduced.
Time for version 1.0: 2 weeks (PL)
Time for version 1.1: 1 week (PL)
DEPENDENCY CHECKER
This module is currently working for C only. More languages are to be added.
Code from the SCons project can be used. Since adding support for a language
is not much work, it can be done by volunteers.
Time for version 1.0: A day per language. (volunteers)
Time for version 1.1: -
CROSS REFERENCER
This implements the "cross referencer" module of the design. Only the
interface with the recipe executive has been done so far. The actual
design and implementation still needs to be done.
The work includes:
- Deciding what to use as a base. Exuberant ctags and GNU ID tools are at
least interesting.
- Designing the file format for the database. For version 1.0 this must be
set in stone.
- Implementation of scanning a few languages.
- Implementation of the lookup program. Must be able to communicate with the
recipe executive to retrieve files.
The core must be done by the project leader. Once this is working, volunteers
can add more features and support for more languages. The design must be done
in such a way that adding support for a language is simple.
For version 1.0 the basic structure is set into place. For version 1.1 the
implementation is to be done.
Although this work package is important for A-A-P, it could be reduced
considerable without affecting other work packages. This could be done by
using an existing cross referencer instead and interfacing it with A-A-P. The
work is then reduced to one week.
Time for version 1.0: 2 weeks (PL)
Time for version 1.1: 3 weeks (PL) 4 x 1 week (volunteers)
VERSION CONTROL WRAPPER
This implements the "version control wrapper" module of the design. This is
currently mostly working for CVS. For version 1.0 this needs to be done:
- Implement at least one more version control system, one that is quite
different from CVS (uses file locking). This verifies that the syntax of
version control commands is good. Otherwise this implementation can be
quite primitive where it overlaps with features that have already been
tested with CVS.
- Improve the CVS support. E.g., support for version tags (selecting a stable
or current release).
- Support for other version control systems may be added by volunteers.
- Add minimal support for generating a patch that describes the changes
between the current files and a certain committed version.
- Testing: Verify that the code works in various circumstances.
- Fix bugs.
- Improve the documentation.
No additional work is planned for version 1.1.
Time for version 1.0: 2 weeks (PL), optionally 1 week per VCS (volunteers)
Time for version 1.1: -
PERSONAL VERSION CONTROL
This implements the "personal version control" module of the design.
Nothing has been done on this for version 0.1.
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 1.0: -
Time for version 1.1: -
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 a minimal implementation has been done. It relies on external
commands (e.g., a web browser). Support for specific issue trackers could be
added. Since existing recipe commands are used, this work can very well be
done by volunteers.
Time for version 1.0: 1 week per issue tracker (volunteers)
Time for version 1.1: -
GUI IDE
This implements the "GUI IDE" module of the design. For version 0.1 only the
interface with the recipe executive was worked out. For version 1.0 a lot of
work is to be done:
- Set up the framework in which tools can work together. Select the base to
be used for this, starting from scratch would be too much work. IDLE could
be the base, perhaps there is something even better.
- Design the basic layer for the interfaces. This could use different
mechanisms on different systems (e.g., MS-Windows messages and sockets).
- Design every interface. Examples should be used to speed up the work (e.g.,
Netbeans).
- Implement every interface at least once. This very likely uses Vim as the
editor and gdb for the debugger. The cross referencer module is also
involved.
- Implement the use of a recipe as a project file.
The goal for version 1.0 is to have a working system, but minimal on features
and only supporting one tool for each purpose. The design of the interfaces
is complicated, thus must be done by the project leader. A first
implementation must be done by the same person in parallel with the design.
This must be done up to a level that volunteers can add more tools and add
features. Volunteers are also needed to improve the looks of the GUI.
The planning is very tight. When running out of time this will result in less
functionality.
Time for version 1.0: 7 weeks (PL), several weeks (volunteers)
Time for version 1.1: several weeks (volunteers)
CONSOLE IDE
This implements the "console IDE" module of the design.
All issues concerning recipes and interfaces are covered by the GUI IDE.
Providing IDE functionality in a console can be postponed until after version
1.0. What is easy to do once the GUI IDE interfaces have been defined is
starting another application and communicating with it. Thus only using
existing mechanisms.
Time for version 1.0: -
Time for version 1.1: 1 week (PL)
AUTOMATIC CONFIGURER
This implements the "automatic configurer" module of the design. This does
not include the work done for ports. It is best described as an autoconf
replacement that works with A-A-P recipes.
The interface with recipes is unlikely to be different from using autoconf
(shell script), thus this can be postponed until after version 1.0.
Optionally a volunteer can start on this.
Time for version 1.0: -
Time for version 1.1: -
FILETYPE DETECTION
This module was split off from the recipe executive when it became clear that
the functionality is used from several other modules. It was completely
implemented in version 0.1. No work is planned for version 1.0 or 1.1.
WEB SITE
The web site is working and mostly complete. For version 1.0 it needs to be
kept up to date. No drastic changes are to be done. An new item is adding a
page with success stories, which is not much work.
Not included here is the work for recipe distribution, that is now in the
recipe finder module.
Time for version 1.0: 1 week (PL)
Time for version 1.1: -
USER DOCUMENTATION
For version 0.1 the documentation was setup in Docbook format. But the layout
is still to be done. A good index and some kind of search facility is to be
added. A separate manual page is to be added.
The user manual still needs a lot of work. But it does not need to be
completely finished, so long as most users will be able to find the
explanations they need. It must be easy to read for someone starting to use
A-A-P.
Excluded here is describing the recipe format, that is in the "recipe syntax"
work package.
Some of the documentation work is postponed until version 1.1.
Time for version 1.0: 2 weeks (PL)
Time for version 1.1: 1 week (PL)
EXAMPLES
A few examples will be made with A-A-P to show how it can be used. These
should give a casual reader a good impression of the advantages of using
A-A-P. Deciding which examples will be made is part of the work.
Possibilities are converting a project from using Makefiles to using recipes,
a clever solution for maintaining a web site, distributed open source
development, etc.
Time for version 1.0: 2 weeks (PL)
Time for version 1.1: -
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.
- Communication with A-A-P developers, mostly through e-mail.
- Describe each item that can be done by a volunteer in such a way that
someone can decide to pick an item and work on it.
- Make further plans.
Some work is to be done for promotion after version 1.0 is ready, this is
planned for release 1.1.
Time for version 1.0: 2 weeks (PL)
Time for version 1.1: 1 week (PL)
PLANNING
========
The work for version 1.0 starts January 2003. Summing up the total time for
version 1.0 and 1.1 of the Project Leader in weeks:
1.0 1.1
RECIPE SYNTAX 2 -
RECIPE EXECUTIVE 3 1
PORT RECIPE - -
RECIPE FINDER 2 1
CROSS REFERENCER 2 3
VERSION CONTROL WRAPPER 2 -
GUI IDE 7 -
CONSOLE IDE - 1
WEB SITE 1 -
USER DOCUMENTATION 2 1
EXAMPLES 2 -
PROJECT MANAGEMENT 2 1
---- ---
total: 25 8
Taking into account 10% for holidays this results in a development time for
version 1.0 of about 6.5 months. Version 1.0 should be available halfway July
2003. Version 1.1 follows two months later, halfway September 2003.
Compared to the previous version of this plan, version 1.1 is delayed by about
three months. This is caused by:
- More functionality and quality in version 0.1 than planned. Especially the
work on the port recipe and better documentation. This was added to get
more response on version 0.1.
- Work originally planned to be done by volunteers has been shifted to the
project leader. Mainly for the GUI IDE and cross referencer. The
experience from the past half year has learned that it is unlikely
volunteers will be found to do more than small pieces of work.
The plan for version 1.0 and 1.1 is very tight. There is no room for handling
unexpected problems or including a good idea that comes up. Since unexpected
things can happen anyway, some room is needed to absorb delays. If there is a
significant delay, the work for the Cross Referencer can be largely omitted.
Only supporting an existing Cross Referencer is the fall back scenario then.
When a small delay is to be taken care of, this can't be done by taking a few
weeks from the Cross Referencer, because it is unlikely to result in an
acceptable program. It will be better to reduce the work on the Recipe Finder
and the User Documentation, each by one week.
TRACKING PROGRESS
To break up the long period between version 0.1 and 1.0, a version is to be
released in between. Let's call it 0.5. This would include:
- A more stable recipe executive. Even better suited for real work, so that
more people will actually start using it. Their feedback can be used to
improve the quality of version 1.0.
- A first version of the GUI IDE. This should get more people interested,
especially Vim users. After this release the GUI IDE will be mostly
developed by volunteers.
The main advantage of putting this functionality in version 0.5 is that there
is a lot of uncertainty in the development of the GUI IDE. With this
milestone we put pressure on getting the GUI IDE done in the planned time. If
this fails we know the plan needs to be adjusted.
The work to be done for version 0.5:
- GUI IDE 6 weeks
- Recipe Executive 1 week
- Recipe Syntax and Project Management 1 week
Total after adding 10% holidays: about 9 weeks.
Version 0.5 should be ready March 7.
This leaves one week of work for the GUI IDE after release 0.5.
Progress can be reported related to how much of each work package has been
done. Since the work of volunteers is highly unpredictable, and this work is
related to what the project leader is doing, the order in which the work is
done must be flexible. Therefore it is not useful to set further deadlines in
the period until version 1.0. How much of the planned work has been done
should be a good indication of whether the deadline for version 1.0 will be
met.
vim: set tw=78 ft=text :