LCFG Server Rewrite Meeting 25 April 2008

Present: Simon Stephen Alastair Paul

Agenda Bashing

What

Who

When

How

What

What are the boundaries?

Should existing profiles still compile with the new compiler?

Paul is concerned that we may end up replicating, or rewriting chunks of code that implement features that we don't want to support in the long term. Simon and Stephen are concerned about ensuring that we can still build current profiles, and that we don't end up with the specification shifting along with the code.

We should maintain a list of "things that suck", and evaluate options for how we can change them, even if we don't make those changes in the current pass. It would be very good to document these things so that we know about them for future thought.

We don't want to make a dogmatic decision about this. Instead we'll assess things on a case by case basis. Each time we want to change something that has end-user visibility we will create a bug entry proposing it which will clearly outline what we're changing, what the benefits for us are, and what the impacts of those changes on users are. The proposal would then be assessed on those merits.

Object design should take into account the high level features that we might want to modify, such as replacing the compiler, or changing dependency formats. However, it shouldn't consider the implementation details of these changes at this stage. These possible changes should also get recorded as bugs in our bug tracking system.

How do we know when we're done?

We're just rewriting the server. Not the client, not the monitoring system. We're aiming to acheive parity with where we are now. Stephen would like us to come up with a prioritised plan to define 'done' - Simon likes the model of being done when everything that should be an object is an object.

Who

Alastair would like to project manage from a resource point of view. Simon and Stephen will do the bulk of stage 1, Paul would like to be involved heavily in stage 2, and be involved in the work for stage 3 (see below for stages).

When

Stage 1 now till August, building permitting

Stage 2 in August, resources permitting

Stage 3 from September

How

We're going to create a new Bugzilla and SVN repository for LCFG, which will initially contain just the server, and eventually all LCFG code that we export. We're doing this so we have a clear separation between exported, and non-exported activities, and so we can easily grant access to non-affiliated individuals.

Stage 1: Tools

Install:

Bug tracking system (highest priority, so we can start identifying issues as soon as possible)

Version control system

Integration server

We think the bug tracking system will run on dresden, the integration server on a new bit of kit, and we're not sure about the vcs.

Test suite: We'll build a test suite that's based on

Using the existing LCFG tests, in their existing framework

Using a subset of the existing profiles and checking the XML that they generate against a canonical copy

Stage 2: Code inspection and tidying (August)

we want to have perlcritic as a test. This step will take the current code, and make it clean under a set of to-be-agreed perl critic rules, so that any refactoring changes which result in perlcritic errors can be clearly identified.

at the same time we will

identify candidates for deprecation, recording them in bugzilla. We'll perform impact/benefit analysis on each of these, and announce those features we intend on removing as we go.

identity possible future changes, and record these in bugzilla.

Stage 3: (September)

* Do some work - picking off bits

at the same time we will:

identify candidates for deprecation, recording them in bugzilla. We'll perform impact/benefit analysis on each of these, and announce those features we intend on removing as we go.

identity possible future changes, and record these in bugzilla.

Implementation languages

We discussed the use of Moose as an object model. Paul and Alastair expressed concerns about Moose, given its pervasive nature, the question of long term support and additional learning curve, against its usefulness. They will go away and examine these further with a view to making a decision by September.