On 9/23/19 3:41 PM, Brendan Higgins wrote:
On Tue, Sep 17, 2019 at 11:41 AM David Gow davidgow@google.com wrote:
TL;DR: We expect KUnit to be accepted upstream into Linus' branch in the next week or two, and we now need to figure out what we are going to do with our non-upstream 'kunit/alpha/master' branch.
Given that it has been about a week and we haven't heard any comments, complaints, or concerns about this. I assume that there are no strong opinions against this, and people will be generally okay with this strategy.
As mentioned previously, we are expecting to see KUnit make it into torvalds/master this merge window (the next week or so), so we will probably update/rename kunit/alpha/master shortly thereafter.
Cheers
Hello everyone,
We've put together a rough proposal of what we should do with our not-upstream branch, known to most people using it as 'kunit/alpha/master'[1], now that KUnit's acceptance into mainline appears to be imminent (the KUnit MVP patchset is now in linux-next, and the merge window just opened).
========== Background ==========
KUnit development is currently split between two versions: the 'kunit/alpha/master'[1] git branch, and the version being submitted to the upstream Linux kernel. While there are some good reasons to continue to have two separate versions of KUnit, at present there is some uncertainty around the difference between these versions, and in which circumstances each version is useful.
At present, the 'kunit/alpha/master' branch serves a few different purposes. It is a place for code not-yet-ready for upstream -- such as the mocking framework -- while being developed, while also acting as a stable version for customers who do not wish to follow along with the changes made during the upstreaming process. Adding to the confusion, the name 'kunit/alpha/master' refers to an early (alpha) version of KUnit, and the version of KUnit being upstreamed has now diverged significantly from this version, requiring significant differences in documentation, and requiring a number of changes to tests when porting from one version to the other. Finally, it is not clear how the 'kunit/alpha/master' version should evolve as features it contains are upstreamed.
On the other hand, the version being upstreamed has its own complications. It contains significantly fewer features (as features such as the mocking frameworks will be upstreamed individually), and so is less useful for the average customer. Until each feature is upstreamed, it is iterated on rapidly to address comments from the kernel community, so in-progress features are not stable enough to reasonably build on. Finally, it exists only as a set of patches on mailing lists, rather than as a maintained git repository (due to the fact that the patches themselves are changing rapidly), making it difficult for early adopters to incorporate into their own trees.
Whilst we believe there to be enough (at times conflicting) goals above to justify having multiple versions of KUnit, we want to ensure that they are meeting their goals, and that we have a process to ensure that code finds its way into the correct version, that we can deprecate and remove failed experiments or superseded versions, and that we can keep pace with upstream kernel releases.
============ The Proposal ============
We propose having two tracks of development: the upstream kernel (comprising both code that has been upstreamed, and code which is in the process of being upstreamed -- i.e. is being reviewed on the mailing lists), and an 'experimental' branch, which contains features which are yet to be submitted upstream.
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.
thanks, -- Shuah