On 5/9/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
i would like to suggest that JAMES adopts a slightly different
approach to the development of extra and alternative functions. ATM we
use branches for experimentation but i think that these are several
disadvantages in this:
* collaboration is more difficult
* hard to shared between branches
* more difficult to compare and contrast different approaches to
similar problems
* hard to take advantages of improvement in code made on the trunk
with the new modular system i think that it should be possible to
develop addition and alternative functions in trunk by using
experimental modules.
so, i would like to propose we allow experimental modules in trunk.
these will be prefixed 'experimental' and contain either alternative
implementations or new functions which are not yet mature enough to be
a full part of JAMES. these modules would not be included by default
in JAMES but would included as part of the unified build and could be
added in by altering the configuration.
opinions?
Sounds like a billiant idea. Will it work, though?
Won't this over time lead to a trunk swamped with half-baked years-old
experiments?
What if the experiment is to change how modules are working together?
(Current modules have very tight coupling.) This would have to be done
on a branch nevertheless, if we wouldn't want to break what's in
TRUNK.
The motiviations for the proposal are very valid. We need a way to
"plug-in" (experimental) functionality (modules).
Today, we fork the whole James Server in branches/sandbox. This is
bad. We must have an architecture where we can (more) easily plug in
modules, whereever they come from (sandbox/third party).
My approach would be to fix the server architecture (APIs, interfaces,
container) first, instead of moving experiments from sandbox to trunk.
The module refactoring is an important first preparational step. But
at some point we have to fix our application, so it can support the
module concept properly.
What I'd like to see is to move experiments to trunk as soon as they
become alpha-quality and could be deployed/released to our users.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
