From: Jiri Kosina <jikos@kernel.org>
To: Fengguang Wu <fengguang.wu@intel.com>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] Nominating Fengguang Wu - 0-day
Date: Fri, 29 Jul 2016 01:38:36 +0200 (CEST) [thread overview]
Message-ID: <alpine.LNX.2.00.1607290131390.24757@cbobk.fhfr.pm> (raw)
In-Reply-To: <20160728230713.GB18980@wfg-t540p.sh.intel.com>
On Fri, 29 Jul 2016, Fengguang Wu wrote:
> I need your understand that there are severe limitations what useful
> contents we can provide due to the nature of merge-test-bisect. For
> example, there will be no build logs specific for your branches/commits
> because the extensive build tests are possible only because your code
> are tested together with a large number of random others.
I think this'd be an interesting thing to discuss per se, as my personal
feeling is that the expectations of maintainers / git tree owners might be
slightly diverging from reality.
The reason I am bringing this up is a very recent example here:
https://lkml.org/lkml/2016/7/28/212
The 0day bot identified my patch as a build-breaker, and it took me quite
some time to figure out that this has been actually broken for years
already (IOW yes, the treee fails to build with some configs after my
patch has been applied, but I'm pretty sure it breaks with the same config
even without my patch).
Hence, if you could explain in a little bit more detailed way how
developers should interpret the reports, I'd be very grateful for such
session.
Special focus should probably be put on regressions -- once reported by
your bot, I'd love to know the last-known-good base to compare against.
Oh, and thanks a *lot* for all the 0day efforts, I am pretty sure that it
increases the speed of development while maintaining the quality, and a
status update from you should IMO always be a welcome KS topic,
--
Jiri Kosina
SUSE Labs
next prev parent reply other threads:[~2016-07-28 23:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-25 19:01 Luis R. Rodriguez
2016-07-25 20:23 ` Alexandre Belloni
2016-07-26 3:10 ` Vinod Koul
2016-07-26 8:16 ` Laurent Pinchart
2016-07-26 8:56 ` Vinod Koul
2016-07-28 13:20 ` Fengguang Wu
2016-07-27 14:50 ` Fengguang Wu
2016-07-28 16:15 ` Laurent Pinchart
2016-07-28 20:53 ` Fengguang Wu
2016-07-28 20:59 ` Laurent Pinchart
2016-07-28 22:38 ` Dmitry Torokhov
2016-07-29 16:26 ` Vinod Koul
2016-07-28 23:07 ` Fengguang Wu
2016-07-28 23:33 ` Luis R. Rodriguez
2016-07-29 0:09 ` Fengguang Wu
2016-07-29 15:12 ` Bjorn Helgaas
2016-07-30 17:05 ` Luis R. Rodriguez
2016-07-30 17:24 ` Guenter Roeck
2016-07-31 6:35 ` Fengguang Wu
2016-07-31 17:32 ` Vinod Koul
2016-08-01 13:35 ` Fengguang Wu
2016-07-28 23:38 ` Jiri Kosina [this message]
2016-07-31 11:16 ` Fengguang Wu
2016-07-29 2:00 ` Steven Rostedt
2016-07-29 2:26 ` Fengguang Wu
2016-07-27 14:41 ` Fengguang Wu
2016-07-28 17:15 ` Guenter Roeck
2016-07-28 17:21 ` Dmitry Vyukov
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=alpine.LNX.2.00.1607290131390.24757@cbobk.fhfr.pm \
--to=jikos@kernel.org \
--cc=fengguang.wu@intel.com \
--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