On 5/10/07, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
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?
only time will tell :-)
Won't this over time lead to a trunk swamped with half-baked years-old
experiments?
periodically trunk would need cleaning perhaps every six months and
definitely before each new release. if no one is interested in
maintaining an experimental code base, we tag and delete.
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.
IMHO loosening the coupling is necessary to take JAMES forward in any case
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).
+1
My approach would be to fix the server architecture (APIs, interfaces,
container) first, instead of moving experiments from sandbox to trunk.
i worry about finding the energy to perform this work first
whilst people are all just working in their personal branches, there
is no incentive to maintain or change the common code base in trunk.
the code bases are drifting apart and the longer this goes on, the
less chance that anyone will ever be able to put then back together.
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.
i think that this approach is bad for the development community. by
each working in our own personal branch, we lose sight of each other's
code. we cannot learn from each other and we cannot share libraries.
trunk is unlikely to be released any time soon and i think that this
is an ideal time to experiment with our process. we can try
experimental modules without great risk. if they haven't worked then
we can abandon them before the next release.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
