Does it do any actual harm to have a branch, even if not everyone thinks it's necessary? Presumably that gives the people that want stability a place to work and at worst they've bought themselves some extra work merging back into the main development stream later.
My previous experience (3 major occasions) has been that code branches often turn out to be more trouble than they are worth, but just occasionally they can be the right answer. Geoff. On 08/02/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
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]
