From: "Levin, Alexander" <alexander.levin@verizon.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>,
"Levin, Alexander" <alexander.levin@verizon.com>
Subject: Re: [Ksummit-discuss] Self nomination - Sasha Levin
Date: Fri, 26 Aug 2016 09:51:41 -0400 [thread overview]
Message-ID: <20160826135141.GD25341@sasha-lappy> (raw)
In-Reply-To: <20160826121119.GA29929@kroah.com>
On Fri, Aug 26, 2016 at 08:11:19AM -0400, Greg KH wrote:
> On Fri, Aug 26, 2016 at 01:55:27PM +0200, Julia Lawall wrote:
> > Not sure if I was clear about what I was asking you to agree to :)
> >
> > Basically, we can take the patches sent to stable and the patches not sent
> > to stable as a training set, but then the machine learning comes up with
> > some algorithm that produces some results. An expert is needed to evaluate
> > the results. Ie for a thousand (number chosen at random) patches, if the
> > algorithm says it is a bug fixing patch, is it or isn't it, and vice versa.
> > Of course, we could also evaluate on patches that previously have and have
> > not been sent too stable, but there is a problem there, because our goal is
> > to have more patches sent to stable than are already being sent there, so we
> > need to show that the algorithm can capture what humans are missing.
>
> I think that is very interesting research and I would be glad to help
> out with it how ever I can, as the result might be very useful for us.
>
> So sign me up!
I'd be happy to do this as well.
Per Greg's advice, I'm reviewing distro kernels for upstream commits that
they carry which should have been in our LTS trees, those commits usually
aren't tagged in any way and can be a good set of commits for training or
validation.
I do think that we should be using the algorithm to produce a list of authors
and maintainers who don't provide proper tags when they should and have a
discussion with them about why that doesn't happen and how we can help them
to get it "right" (vs just using the algorithm to apply patches).
--
Thanks,
Sasha
next prev parent reply other threads:[~2016-08-26 13:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-26 4:46 Levin, Alexander
2016-08-26 11:26 ` Greg KH
2016-08-26 11:42 ` James Hogan
2016-08-26 11:50 ` James Hogan
2016-08-26 12:27 ` Jani Nikula
2016-08-26 12:39 ` James Hogan
2016-08-26 11:56 ` Greg KH
2016-08-26 12:17 ` James Hogan
2016-08-26 13:44 ` Levin, Alexander
2016-08-26 11:48 ` Julia Lawall
2016-08-26 11:55 ` Julia Lawall
2016-08-26 12:11 ` Greg KH
2016-08-26 13:51 ` Levin, Alexander [this message]
2016-08-26 13:55 ` Julia Lawall
2016-08-26 18:52 ` Levin, Alexander
2016-08-26 19:59 ` Julia Lawall
2016-08-26 12:08 ` Julia Lawall
2016-08-26 18:55 ` Levin, Alexander
2016-08-26 13:39 ` Levin, Alexander
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=20160826135141.GD25341@sasha-lappy \
--to=alexander.levin@verizon.com \
--cc=gregkh@linuxfoundation.org \
--cc=ksummit-discuss@lists.linuxfoundation.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