On Jul 3, 2006, at 3:30 PM, Kevin Williams wrote:
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.
I agree on two streams being very confusing. When we did the sandbox
version, we took what we could from the trunk as a starting point.
Maybe there is something we missed amongst all the refactoring that
went on but even if there is, I don't think it is much.
If only the sandbox has value then why not tag the trunk and copy
over the entire sandbox? My two cents.
That was Jeremy's proposal as well. I think this makes the most
sense, and even if we missed something in the original M1, it seems
easier just to factor it back into a copy of the sandbox rather than
replaying the merge we did with the initial sandbox development.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
