You are here
LCFG Server Refactoring
Description: A project to rewrite the LCFG server to be cleaner and easier to maintain and develop, without significant change in functionality.
Deliverables: New LCFG server code.
Customer: All LCFG users.
Case statement: The LCFG server code has grown over many years and is virtually unmaintainable. There is a significant risk that the existing code base might not run "as is" on future DICE platforms. Further developments of LCFG are also stalled because of the difficulty of extending the existing code.
Status:
Timescales: Project to start in June 2009
Priority:
Time:
Proposal: It is the project team's view that it would be difficult/impossible? to produce a detailed plan at the outset of the project.
Instead, we will plan our work on a month-by-month basis. We will produce, at each
development meeting, a report on progress made in the past month and an action plan for the current month.
We will review, biannually, effort expended and progress made in order to decide whether to continue with the project.
Resources: Substantial design/programming resources required.
Plan:
- Produce test suite
Produce a test suite so that we can ensure that code changes don't affect the
behaviour of the compiler. For now, only interested in "system" testing - ie generated profiles.The test suite :-
- must cope with testing uncommitted code changes
- must be portable so that developers can run it on their own machines
- will include a snapshot of every header file, package list, default/schema
files, source profiles plus the profiles for the source profiles as generated
by the existing compiler.
It is expected that the bulk of the work is in producing a "difftool" to
compare the output of the modified compiler with that of the existing compiler.Estimate 7-8 days of effort.
- Improve coding standards
Bring existing code up to modern perl coding standards :-
- everything passes perl critic (at some level of perl-critic acceptance)
- turn on use strict and use warnings
- use subset of perl to improve readability
- use perl-tidy (need to agree on perl style)
- pod sanity and coverage checks
- will review changes (at file granularity) before commit (? submit patch via bugs?)
Estimate 5 days of effort (might stretch). Can parallelize work across team, as long as communicate well.
- Mkxprof running as normal user
Modify mkxprof code to run as normal user rather than as root
Estimate 2-3 days of effort.
Dependencies:
Risks: Throughout the project, there is a risk that we will underestimate the effort required to understand and re-engineer particular sections of the existing code.
URL:http://wiki.lcfg.org/bin/view/LCFG/LcfgBrainstorm
Milestones
Proposed date | Achieved date | Name | Description |
---|---|---|---|
2010-04-30 | 1.0 | Produce test suite | |
2010-02-28 | 2010-01-31 | 2.0 | Switch package building to Module::Build |
2010-02-10 | 2009-09-30 | 3.0 | Run all Perl code through perltidy |
2009-10-26 | 2009-09-30 | 4.0 | Remove all pre-processed Perl files and replace macros with a module to handle configuration. |
2010-01-31 | 2010-01-31 | 5.0 | Perl critic level 5 |
2010-02-14 | 2010-02-28 | 6.0 | Perl critic level 4 |
2011-08-11 | 2010-04-28 | 7.0 | Fix major causes of warnings |
2010-02-28 | 2010-02-25 | 8.0 | Rewrite mkxprof commandline handling |
2010-04-30 | 9.0 | Add git support to LCFG build tools. | |
2011-09-30 | 10.0 | Replace various database interfaces with Object-Oriented classes. | |
2011-10-30 | 11.0 | Refactor the mkxprof script into an Object-Oriented class using Moose so that the huge number of global variables can be become attributes. This would make the coder safer, easier to read and maintain, and would permit the automated handling of command-line options and configuration files. |