Cleanup Fest Aug 2010¶
The framework is in need of a major reorganization and cleanup.
This effort is long overdue and it appears that we will not be
able to do it unless we take a break from normal activities
and do as much as possible during this period.
The period will be starting on Tuesday Aug 31th through Thursday Sept 2nd.
Large task list¶
We have a brainstorm last week at the status meeting and listed
all the possible items that might be worked on (or at least started).
Here is the unedited list.
- Directory levels in the repository (bad names and too many levels) (1) # Message logger productization and namespace renaming (1) # cmake integration issues (install / build directories / environment variables (1) # Removal or CMS debris (1) # Test framework and getting some tests in place (2) # Event setup removal and other dead feature removal (2) # Namespace changes (cms::Exception is example) (2) # Plugin manager fixes, reduction, and better naming conventions (3) # upgrades (boost, compiler, ROOT) (4) # Product-to-product references (4) # Configuration language replacement (5) # Product grouping documentation (5) # Documentation gathering (from CMS and mu2e and elsewhere) and editing it (5) # Persistent product definition rules - simplification and clarification (5)
In addition, Rob wants to see the debug release build include detailed C++
rule checking (many more warning than the default).
We had a discussion about overall structure on Monday Aug 23rd.
Lynn's notes from this discussion are below. I also took notes, but lost all
of them when the MacOS update manager killed my browser.
Marc and Walter will do some preliminary work on sketching out the structure
of the packages.
The number on the end of the above list is the priority I've assigned to it.
Feel free to comment and edit.
How we will run the fest¶
Everyone that is participating will meet in the scrum room and we will spend
the time there working on the issues. Before next Tuesday, we should have a
prioritized list of task that we can work on. In the scrum process, work comes
in the form of a user request written as a short story. The stories are
broken down into task with time estimates on them, and the task are organized into
collections that last the duration of the work period. Our situation is not exactly
that because of our single work period, but we can create the list of tasks, what
they pertain to, an importance factor, and an ordering constraint.
Some of the items on the brainstorming list will obviously take more time than
we have available. We will need to concentrate on the preparatory work
(e.g. cleanup and restructuring) to allow work to proceed in the future.
For the first step, it is important that we all know the current packages and the structure that
we are transforming it to.
The whiteboard planning images are attached at the bottom of this page.
- where to work (oink) * gcc version (latest on oink) * boost (newest that works with compiler version) * root latest good one
1. define cmake rules for running tests
3. lay out cmake build and integrate new MF & friends & use of env
4. make cmake deal / factory and plugin issues
5. cmake build of persistent products
1. build boost
1. build root
1. CLHEP needed?
1. create art repository + redmine site (cdcvs / git)
1. review of proposed package reorg and structure
1. start of repackaging of MF into the four parts
2. populate repository
3. source modifications for new packaging
3. removal of event setup and other debris
1. new top-level configuration (python replacement)
3. new factory and plugin lookup rules
3. write and run scripts to fix calls to pset getParameter
3. implement new configuration
3. implement changes to plugins
We had a preliminary meeting yesterday to discuss reorganizing framework. Here is the status:
1. framework will be renamed "art"
2. I presume the executable will be art, instead of either fw or mute.
3.. An art release will have the following structure:
4. include directives will read #include "art/package1/header.h"
5. installed directories will be under $ART_HOME, which would be the same as the ups directory $ART_DIR. The directory structure would be:
$ART_DIR/bin (executables and scripts)
$ART_DIR/lib (regular and plugin libraries)
6. $ART_DIR/bin will be added to PATH
7. $ART_DIR/lib will be added to LD_LIBRARY_PATH
8. Examples will be extracted into a separate product, to be called "gallery".
9. $ART_CODE will point to the source code, if it is available. Source code is only needed by the developer and library manager. Anything needed by the end user will be installed.
10. The development build structure will mirror the installed structure in the important details. Developers and library managers will use the new setup_fw_development script to establish the build environment.