Before:

The procedure for 3.10 was - upload your fix to mantis and it will be
integrated by the build server whose name used to be Edgar, but is now
Bob. i.e. there were 2 inputs.

1. the design of the image (which for 3.10 included the removal of a
couple of packages)
2. the fixes from mantis integrated manually.

After Bob:

1. the design of the image, a task which loads the latest packages,
reorganises the whole image into a DIFFERENT package structure. (how are
you going to support that with mcms?)
2. the fixes from mantis integrated automatically.

Your scheme:

1. People can contribute to trunk...
2. there is no image design because bob is not building images anymore.
3. People can contribute to mantis and those fixes get integrated into
trunk as you go along. So in your scheme the mantis fixes are now being
applied to a moving target. Which means that other people who want to
see what good a fix is for to see if it might be useful to them, have no
idea what state 3.11 trunk was in when the fix was added to it.

So basically the whole commit to trunk idea is not tenable.. for the
following reasons.

1. There is no design of the final image published and coded in advance.
It is now a free for all for the committers that have been let loose on
trunk

2. The packages are going to be reorganised in the process of the image
design.

a) "System" needs to be broken up
b) The Implementation and Tests need to be logically and tidily
organsied for once.

Keith