On Jul 3, 2006, at 5:34 AM, ant elder wrote:

One of the big reasons for me is summed up well in Sebastien's proposal:

"This will get our community members involved in building the runtime
together and will lead to a wider knowledge base that makes it possible to quickly implement new functionality in the future. It will also build a community knowledge base that is ready to help new community members come on
board quickly."

I struggle with understanding the what and why of parts of the sandbox code and hope bringing small bits over one step at a time will help with this.

Could you outline specifically what you don't understand. Perhaps we could do another code walkthrough like we did about a month ago?

Why don't you like this approach? Sure it may take a bit more time but if in the long run we end up with more people understanding the runtime that seems like time well spent even if we end up with most of the trunk being just
whats in the sandbox today.

The key point is I like Jeremy's approach better. The thought of merging M1 with the sandbox code (Sebastien's proposal) doesn't seem to fit based on my technical knowledge of both code bases. More importantly, Jeremy's approach strike me as better. Since I have outlined my reasoning in previous posts (not just technical) why I think it is better,I won't repeat them here, as it will just confuse the ongoing threads.

So, to turn it around a bit, as I've already outlined some of my reasons for liking Jeremy's approach more, do you have additional reasons other than you are having difficulty understanding the sandbox code and your feeling it will be a worthwhile exercise in knowledge sharing? Regarding the later, I think it's better (and more inclusive) to make a concerted effort to modularize and bring people into the sandbox code as that will allow all of the ongoing initiatives (particularly the ones showing Tuscany value add) to continue alongside the knowledge transfer.

Regarding the former, could you outline specifically what you are having difficulty following in the sandbox code so I can try and address it either through explanation or simplification of the code?

 ...ant

On 7/3/06, Jim Marino <[EMAIL PROTECTED]> wrote:

Why would we try this approach as opposed to the one Jeremy proposed,
i.e. moving what is already in sandbox to a branch or even trunk?
Since there are a number of initiatives people are already working on
in the sandbox codebase (e.g. Spring support, deployment,
conversations, data binding, OSGi support, support for new Java C&I
annotations, support for pluggable annotations) it is seems that
making improvements to that according to scenarios people are
interested in will be a nice way to move things forward involving as
many as possible.

Jim

On Jul 3, 2006, at 4:45 AM, ant elder wrote:

> On 6/30/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> <snip/>
>
> 2. Stage the assembly of our M2 runtime.
>> I propose that we start a fresh stream for M2 and build the runtime
>> through
>> baby steps, in parallel with the scenario work. This will get our
>> community
>> members involved in building the runtime together and will lead to
>> a wider
>> knowledge base that makes it possible to quickly implement new
>> functionality
>> in the future. It will also build a community knowledge base that is
>> ready to
>> help new community members come on board quickly.
>
>
> This approach appeals to me. Could we just give it a try for a
> little while
> when everyone is back on Wednesday? If it doesn't work out then all
> the
> other code will still be available in SVN to try another approach.
>
>   ...ant


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to