.
FRDCSA | internal codebases | BOSS

BOSS Architecture Diagram: GIF

Jump to: Project Description | Capabilities

Project Description

• It is an agent, which communicates over (unilang/FL/etc.) which is responsible for several tasks related to source and project management/development.
• Handle setup of preferences for tools used in creating software.
• Ability to create project, or to run tests and recommend/implement changes to project structure to make them compatible with our development model.
• Have an update-rc.d like system that handles the following things: It scans a project for information about hooks that it must register with the system BEFORE they get packaged, so that we can test, develop and use these features, without having to build and install the package for every single change, i.e.
• Yet, when the package is installed, it intelligent selects which hooks ought to be activated between the package and the source system, on certain criteria, and allows hot swapping.
• Create an FRDCSA distribution CD or DVD on demand. Perhaps, use KNOPPIX as a starter.

Capabilities

• /var/lib/myfrdcsa/codebases/internal/boss/scripts/stat.pl can be used in fweb.
• Add flawfinder to boss, and create a more thorough security system.
• Just create a different directory for the new projects, and use the different services, like SVN. boss.
• boss QC Use best practices - verified in perl code using Perl::critic, etc.
• boss QC Setup unit testing.
• Setup a separate project server and begin translating my systems one by one over their, verifying the usage (in terms of quality control) of various different standards. Add QC to boss.
• Write a better version of boss Grep
• Add a no filtering option to "boss capabilities"
• boss capabilities should utilize case if the word is a common word, such as all.
• Replace boss::Config with AppConfig if appropriate. Generate refactorings for all projects. Upgrade them to the latest tech where possible!
• Have to be weary about performing certain operations on boss because of symlinks to the rest of the projects.
• fweb capability listings (boss too) should be organized based on importance.
• /var/lib/myfrdcsa/codebases/internal/boss/perl-codebases/clear/Feedback.pm:use perllib::UI; contains the desired feedback code for clear.
• Create a boss function for diagramming an architecture.
• We should develop a system for developing systems. In other words, boss should have high-level design criteria in mind. In other words, let us have a better defined approach to building systems. To build the TDT, we should (after first searching for other systems) collect data, choose a learner, implement the learner, etc.
• Write subsystem of audience (or maybe fieldgoal or boss) to catch up with other developers
• Build a classifier for architect that concerns which software belongs in which system (or maybe in boss)
• I find that writing a first generation simplistic system gets the basic functionality in place without all the difficulties. It would then be fitting to do an entire rewrite. boss ought to keep track of that kind of information.
• Codemonkey should not only automate that transformation, but it should also work with perform to determine/prove the run time complexity of various algorithms, and work with boss to decide how to implement them. boss had some cool features that were supposed to be done to it, but no mention of those.
• code-monkey should do more code generation. Right now boss framework is a very simple instance of that.
• boss/architect should support most of those metrics in the Schaums system. Could use pse for scheduling?
• boss should keep track of all renamings of projects over time, so for instance, since today we merged Sorcerer into cso, should record that and add it to a log of operations on systems.
• Maybe create some system renaming capability for boss
• boss should do the software risk management
• WRite system that helps me figure out where functionality belongs. Just kidding, this is already part of I think architect, or maybe boss.
• Make this from the radar or predator script get dependencies run on all the boss codebases.
• boss can use the perl source to determine whether all CLI options are covered in the manual.
• The capabilities of the various systems (for instance "boss backup") should have explanations written about them. From these "requirements", both tests as well as documentation may be generated
• Add code to boss to automatically copy over those files.
• Why didn't boss get Calendar and Calendar.pm for event system when run with updatelinks
• Must worry about if boss uncleanly packages a few icodebases, and these are later archived, we will be leaking personal information.
• Need to have boss or whatever, track the popularity and usage of various software. For instance, mysql is being used how often. This information could come from Debian's popularity contest software.
• boss and fweb should use http://readyset.tigris.org/
• Perhaps boss could serve as a system which had "Integration Experiments", "Demonstrations", or "Milestones", etc.
• boss should have the ability to rename an internal codebase.
• Add a function to boss like "boss index ", so that it puts the directory in the project or source hatcheries.
• Add boss capabilities to clean dirs of our projects.
• It is interesting that I can write some code to have boss automatically rebuild packages after I've editted some code. Furthermore, supposing these pass certain tests, they can be uploaded and even clients can be contacted to upgrade automatically. This is a quick way to push the code.
• Add boss detection to manager (dogbert intrusion detection)
• can be useful for boss to upload stuff to sourceforge Module::Release::SourceForge
• radar can use boss to build up models of what other projects are doing and therefore, predict project behaviour over time.
• use http://search.cpan.org/~markov/OODoc-0.90/lib/OODoc.pod for boss documentation project
• Add a boss::Config CLI front end to predator so we can do things like search archived and packaged software by name, etc.