From: Shuah Khan <skhan@linuxfoundation.org>
To: Sasha Levin <sashal@kernel.org>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Squashing bugs!
Date: Wed, 5 Jun 2019 13:05:25 -0600 [thread overview]
Message-ID: <144cc051-52e8-d6ec-e7fc-6545fc23eab4@linuxfoundation.org> (raw)
In-Reply-To: <20190605131942.GD29739@sasha-vm>
On 6/5/19 7:19 AM, Sasha Levin wrote:
> On Tue, Jun 04, 2019 at 11:16:17AM -0600, Shuah Khan wrote:
>> On 6/3/19 4:11 PM, Mark Brown wrote:
>>> On Mon, Jun 03, 2019 at 05:10:04PM -0400, Sasha Levin wrote:
>>>
>>>> Would it make sense to do some bikeshedding around how an ideal email
>>>> bug report should look like, and then get syzbot and maybe kernelci to
>>>> switch to using this new format as an experiment?
>>>
>>>> A bunch the syzbot/kernelci/etc folks will be at LPC as well, and we'll
>>>> have the testing & fuzzing MC going on where this can be discussed and
>>>> agreed on once there is a concrete proposal.
>>>
>>> I think we'll find that there's a lot of variation in what's useful to
>>> report directly in the e-mail and how comes from the particular tests
>>> that are being done, what's critical information about the environment
>>> will vary quite a bit and there's going to be taste differences as well.
>>> A lot of this is a combination of common sense and the reporters being
>>> able to be responsive to feedback from their users, there's not much
>>> commonality in the formatting of the existing reports from static
>>> analysis but they're pretty much all useful (at least the ones I tend to
>>> get are useful to me).
>>>
>>> There is the question of tooling to track the bugs between multiple bots
>>> which would benefit if they were doing standard things but if people are
>>> working on that rather than trying to serve both humans and computers at
>>> once we might be better off with some sort of API and providing a URL in
>>> the emails for the machines to go and look at.
>>>
>>
>> I am going to bounce a proposal and brace for impact :)
>>
>> What do people think about managing bugs the way we handle our
>> development workflow?
>>
>> - Create a directory under our source tree for bugs. This way bugs
>> stay with the source and we manage them the same way we handle
>> non-runtime objects: Documenation, scripts etc. This can be flat
>> directory or have a sub-dir structure underneath.
>>
>> ../bugs similar to ../Documentation
>
> I think that having them in the same tree is going to complicate things
> more than it will help.
>
> It would probably be simpler to have this in a separate tree (or as git
> objects inside Linus's tree).
>
>> - Associate a mailing list - linux-bugs
>> - Define a format in which bugs should be sent to this list and what
>> should be included in the report.
>>
>> e.g: [BUG REPORT] sub-system title
>> Failure mode, release, stack trace (if applicable) etc.
>
> Yes! Hopefully something that is both easily machine readable and human
> readable.
>
Can the AUTO SEL logic be leveraged for updates to bugs?
>> - A group of maintainers/developers (volunteers) take turns to watch
>> this list as a long term plan. Yes, I am proposing a mailing list,
>> consistent with our development model.
>
> I'd be happy to help here.
>
Awesome.
>> - History of the bug including the fix commit ID will be preserved.
>> We will have to figure out what it means to close a bug and general
>> lifetime. There is a big difference between these objects and other
>> source objects. These objects have short lifetime.
>>
>> I haven't thought through everything yet.
>>
>> My motivation is that, this way bug reporting and managing will be part
>> of our workflow and becomes part of our process. It helps centralize bug
>> reports.
>
> Having bugs work the same way like patches is a great approach IMHO.
> Being able to git-send-email bugs, or to use our various autmation tools
> for git commits on bugs is really great.
>
> We have a lot of infrastructure written around our existing git/email
> process, so why not leverage it more as you suggest?
>
Right. I am hoping we can leverage a lot of our existing tools and
processes if we go with the patch process. Maybe be AUTO SEL logic can
also be leveraged and extended to generate bugs reports and/or generate
updates for bugs.
thanks,
-- Shuah
next prev parent reply other threads:[~2019-06-05 19:05 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-30 23:30 [Ksummit-discuss] [MAINTAINERS SUMMIT] Squashing bugs! Shuah Khan
2019-05-31 12:01 ` Laura Abbott
2019-05-31 15:56 ` Shuah Khan
2019-06-03 5:01 ` Leon Romanovsky
2019-05-31 22:15 ` Kees Cook
2019-06-03 10:42 ` Jan Kara
2019-06-04 18:29 ` Laura Abbott
2019-06-03 16:48 ` Shuah Khan
2019-06-02 18:09 ` Sasha Levin
2019-06-03 17:25 ` Shuah Khan
2019-06-03 18:09 ` Konstantin Ryabitsev
2019-06-03 19:32 ` Shuah Khan
2019-06-03 20:48 ` Linus Torvalds
2019-06-03 21:10 ` Sasha Levin
2019-06-03 21:15 ` Jiri Kosina
2019-06-03 21:23 ` Linus Torvalds
2019-06-03 21:28 ` Jiri Kosina
2019-06-03 22:11 ` Mark Brown
2019-06-04 17:16 ` Shuah Khan
2019-06-05 9:27 ` Mark Brown
2019-06-05 11:48 ` Geert Uytterhoeven
2019-06-05 18:16 ` Shuah Khan
2019-06-05 13:19 ` Sasha Levin
2019-06-05 19:05 ` Shuah Khan [this message]
2019-06-04 18:09 ` Laura Abbott
2019-06-05 12:49 ` Sasha Levin
2019-06-04 21:43 ` Konstantin Ryabitsev
2019-06-04 22:02 ` Shuah Khan
2019-06-04 22:22 ` Konstantin Ryabitsev
2019-06-05 17:54 ` Shuah Khan
2019-06-03 20:59 ` Sasha Levin
-- strict thread matches above, loose matches on Subject: below --
2019-05-29 22:34 Shuah Khan
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=144cc051-52e8-d6ec-e7fc-6545fc23eab4@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=sashal@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 read-only IMAP folder(s) and NNTP newsgroup(s).