On 2/7/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Like Venkat I'm also looking for a more stable runtime environment.
I want that stable environment to bring-up end to end scenarios,
including Bigbank, variations of BigBank and Calculator similar to what
we've been running with the C++ runtime, our integration test suite, and
the new integration test cases that I want to add to cover the
requirements on the Wiki. Right now I can't get even simple samples
working with the trunk and we can't run any integration tests as the
itest plugin does not even compile. I understand why the kernel is
evolving so much and so quickly and this is good and exciting, but
integrating all the pieces and making the fixes and improvements here
and there to get the end to end story working is difficult enough...
that we can't be distracted or broken all the time by the refactoring
and ongoing changes in the trunk.
So I think we need a branch to do this stabilization work, with the goal
of having the scenarios and integration tests in place by March. I think
that it will be good for the project if people interested in stabilizing
and improving basic function can do it in a more stable environment
while the kernel is getting refactored in parallel. When the trunk
settles I'll be happy to synchronize with pieces of it, as long as the
samples and integration tests work. I'll try to create the branch some
time tomorrow morning (Thursday) PST.
I'm disturbed by this proposal as I don't think we have consensus in
the community yet on this issue.
If the issue here is that trunk is unstable, then we should stabilize
trunk. None of the current samples will run against trunk because they
are still using the 0.95 apis. I have updated kernel to use the 1.0
ones and I am in the process of implementing the proposal I made on
the list on how to migrate the runtime. I could certainly use help
migrating the samples and itests to 1.0.
If the purpose of the stabilization branch is to prep for a release
(like we did with M2), I would like to know what we are planning to
release. There's a list of "requirements" on the wiki but we've not
discussed those as a community at all. Most of them pertain to new
functionality and I struggle to see how we can "stabilize" code that
is not yet written.
If the purpose is to implement new features, we have a place for that:
trunk. Things like complex properties, XML ordering, contribution
processing, and assembly changes are all kernel features and can all
be implemented in the kernel's trunk without dependency on any
runtime.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
