linux-kselftest.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brendan Higgins <brendanhiggins@google.com>
To: shuah <shuah@kernel.org>
Cc: David Gow <davidgow@google.com>,
	David Chiang <davidchiang@google.com>,
	David Siebert <David.Siebert@l3harris.com>,
	Kees Cook <keescook@chromium.org>,
	Mike Salvatore <mike.salvatore@canonical.com>,
	Pei Huang <peihuang@google.com>, Sagi Shahar <sagis@google.com>,
	Sangsu Ha <sangsu.ha@samsung.com>,
	kunit-dev@googlegroups.com,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>
Subject: Re: kunit: what do we do with the 'kunit/alpha/master' branch?
Date: Mon, 23 Sep 2019 17:05:03 -0700	[thread overview]
Message-ID: <20190924000503.GA97201@google.com> (raw)
In-Reply-To: <5785a414-b726-a2d6-b8a0-d5f4efaed22e@kernel.org>

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@kernel.org> 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!

      reply	other threads:[~2019-09-24  0:05 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
2019-09-23 23:19       ` shuah
2019-09-24  0:05         ` Brendan Higgins [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20190924000503.GA97201@google.com \
    --to=brendanhiggins@google.com \
    --cc=David.Siebert@l3harris.com \
    --cc=davidchiang@google.com \
    --cc=davidgow@google.com \
    --cc=keescook@chromium.org \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mike.salvatore@canonical.com \
    --cc=peihuang@google.com \
    --cc=sagis@google.com \
    --cc=sangsu.ha@samsung.com \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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