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 :