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

On Mon, Sep 23, 2019 at 2:52 PM shuah <> 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

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.

-- David

  reply	other threads:[~2019-09-23 23:00 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
2019-09-23 23:00     ` David Gow [this message]
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 \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).