On Mon, Sep 23, 2019 at 05:19:58PM -0600, shuah wrote: > On 9/23/19 5:00 PM, David Gow wrote: > > 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). > > > > What I would like to see is a freeze on the experimental branch as soon > as KUnit goes into mainline (which is really at the end of this week) > > Start draining the experimental branch with a goal to get all everything > currently staged there mainlined. Yep, that's the plan. Sorry, if that wasn't clear, but we were trying to be intentionally vague about some things to give ourselves room to maneuver. In anycase, we actually want to be pretty aggressive dropping things from experimental as soon as the feature makes it upstream. > Please define clear sunset date for the experimental branch. Without > that we are looking at a lot of pain in the future. I would like to, but I find being able to predict how long it takes to do something upstream to be pretty hard. Especially with large features where people are likely to have strong opinions on. To give you and idea for upstreaming mocking stuff, I see 3 major components: - Basic "class" mocking and parameter matchers (might be able to split them into two parts) - about 7 patches. - Arbitrary function mocking and spying - currently just a couple patches, but I expect a lot of discussion. I am actually hoping we can use some of Knut's work for this. So this is probably a pretty big project. - Platform/hardware mocking and faking - currently also just a handful of patches, but I also expect to get a lot of discussion on this. I could easily see all this taking well over a year; nevertheless, we want to work on other things as well. In fact, from my talk at LPC, it seems like the general consensus is that the mocking stuff is not a very high priority in terms of what the people there wanted to see. So I definitely want to see this all go upstream as soon as possible, nothing would make me happier; however, I think the reality is that there is too much uncertainty to paint a hard deadline. I think it probably makes sense to try to set a roadmap, but I think it will probably end up being pretty rough past Q4. Nevertheless, I am open to alternatives. I know that trying to maintain a staging repo is a lot of work with no long term benefit, and I think any amount of worked saved there can be spent on more useful things. Part of the reason we shared this publicly was that we hoped that smarter more experienced people might be able to save us from some of this pain :-) Looking forward to hearing people's thoughts!
