From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 711127A9 for ; Wed, 5 Jun 2019 13:19:44 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0ADA986E for ; Wed, 5 Jun 2019 13:19:43 +0000 (UTC) Date: Wed, 5 Jun 2019 09:19:42 -0400 From: Sasha Levin To: Shuah Khan Message-ID: <20190605131942.GD29739@sasha-vm> References: <0bc02b84-4d9a-59a7-e6c6-a3b602adca73@linuxfoundation.org> <1018c8ba-61a0-c024-cd98-3b82ebd710ec@redhat.com> <20190602180913.GR12898@sasha-vm> <667d4900-0a9a-d6f8-7012-3c15c2df7da8@linuxfoundation.org> <20190603180953.GA17954@chatter.i7.local> <20190603211004.GU12898@sasha-vm> <20190603221131.GE2456@sirena.org.uk> <6a90bf6c-e9a4-85eb-527c-c4bc3658e779@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <6a90bf6c-e9a4-85eb-527c-c4bc3658e779@linuxfoundation.org> Cc: ksummit Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Squashing bugs! List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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. >- 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. >- 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? -- Thanks, Sasha