My biggest concern is that we not end up with two active code streams.
That would be very confusing to a potential contributor (and me). So,
if there is value in both the trunk and the sandbox then it seems that a
merge is necessary. If only the sandbox has value then why not tag the
trunk and copy over the entire sandbox? My two cents.
Thanks,
--Kevin
Jim Marino wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]