Re: kunit: what do we do with the 'kunit/alpha/master' branch?

[shuah <shuah@kernel.org>]

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