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.