On Mon, Sep 23, 2019 at 2:52 PM shuah <shuah@xxxxxxxxxx> wrote: > > My concern with this approach is either one could outdated. is there a > reason continue in parallel mode. I would rathet see development happen > upstream so we don't have lot of code to be upstreamed sitting in an > experimental branch while upstream keeps moving. It is given that they > will diverge. I definitely appreciate that, and the aim certainly is to have most changes go straight upstream without passing through the 'experimental' branch first. The real purpose of the 'experimental' branch is to have somewhere to keep the mocking functionality before we're ready to upstream it. Given that there are already people using the current version of the mocking framework, we want to provide a smooth-ish path to upstream by providing this branch which is at least closer to upstream than when we are now (and that'll stay as close to upstream as possible through regular rebasing, rather than staying 'stuck' on the older versions). Ultimately, the 'experimental' branch should go away once all of the pieces of the mocking framework have made it upstream, so this is really outlining a transition plan. Now, if we thought that the mocking changes were sufficiently ready, we could try to upstream them soon and kill the old 'kunit/alpha/master' branch without having the intermediate 'experimental' branch. As it is, though, I don't think we feel the mocking framework will be ready for quite some time. So, yes, they'll diverge a bit, but hopefully a bit less than with what we're going now with our 'kunit/master/alpha' branch. Most development that doesn't relate to the mocking system should go directly upstream, and we'll try to minimise the divergence in the 'experimental' branch by rebasing it regularly on top of any upstream changes. When in doubt, though, KUnit changes should definitely be going upstream rather than to this 'experimental' branch. Hopefully that minimises the divergence and makes this more tolerable. Cheers, -- David
