archive mirror
 help / color / mirror / Atom feed
From: shuah <>
To: Brendan Higgins <>,
	David Gow <>
Cc: David Chiang <>,
	David Siebert <>,
	Kees Cook <>,
	Mike Salvatore <>,
	Pei Huang <>, Sagi Shahar <>,
	Sangsu Ha <>,,
	<>, shuah <>
Subject: Re: kunit: what do we do with the 'kunit/alpha/master' branch?
Date: Mon, 23 Sep 2019 15:52:26 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 9/23/19 3:41 PM, Brendan Higgins wrote:
> On Tue, Sep 17, 2019 at 11:41 AM David Gow <> 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.

-- Shuah

  parent reply	other threads:[~2019-09-23 21:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-17 18:41 kunit: what do we do with the 'kunit/alpha/master' branch? David Gow
2019-09-23 21:41 ` Brendan Higgins
2019-09-23 21:45   ` Siebert, David
2019-09-23 22:26     ` Brendan Higgins
2019-09-23 21:52   ` shuah [this message]
2019-09-23 23:00     ` David Gow
2019-09-23 23:19       ` shuah
2019-09-24  0:05         ` Brendan Higgins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).