Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Squashing bugs!

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Mon, Jun 03, 2019 at 01:48:22PM -0700, Linus Torvalds wrote:
>On Mon, Jun 3, 2019 at 11:10 AM Konstantin Ryabitsev
><konstantin@linuxfoundation.org> wrote:
>>
>> May I recommend using a project like git-bug [1] instead of a mailing
>> list?
>
>I'm not a huge fan of mailing lists only for bug handling, but on the
>other hand, I do think that a bug handling thing fundamentally needs
>
> (a) automatic aging out of bug reports
>
> (b) targeted push notifications (ie ractically speaking - email)
>
>and that the email part is important. And it can't just be a "hey,
>something changed". It needs to contain enough information in the
>email to give a developer sufficient knowledge that the developer
>knows whether it's even worth it looking deeper at the bug, and
>looking at the database (in fact, it should contain enough actual
>information that for simple issues, the developer should go "D'oh!"
>and just fix the bug).

Yes, I was envisioning a mechanism with two different moving parts -- 
one the actual bot that would find and create bug entries in a 
distributed system like git-bug, and another an alert and collaboration 
tool that would monitor and notify developers when a bug is created 
matching the parameters they have defined. For example, Greg can define 
a query matching "all bugs mentioning usb" and attach the action of 
"send bug summary to the mailing list." We can run the matching and 
notification daemon at kernel.org, or anyone can set it up to run it on 
their own system to fire as a post-update hook on when they pull the 
git-bug repo.

These are the upsides for a distributed system like this:

1. Doesn't require a stable internet connection when running on the 
laptop of a developer who's out in a remote corner of the world (except 
for the actual pull to fetch new data).
2. Provides full bug history for the project that doesn't depend on 
kernel.org not falling off the face of the earth.
3. Offers ability to easily analyze the data, including historical (the 
same way public-inbox on lore.kernel.org/lkml allows anyone to crunch 
full kernel development history).
4. Can hook into other bugtracking systems like bugzilla, Gitlab, or 
Github via one-way or two-way bridges. E.g. instead of "send an email to 
the list" for USB bugs, the action can be "create a bug on 
bugzilla.kernel.org and sync back comments and bug status changes." The 
bridges for launchpad and GitHub already exist for git-bug.
5. Bots can check for duplicates before creating a new bug (I'm not 100% 
sure how well this would work, but theoretically this is possible). This 
includes bugs created by other bots, as long as they all feed the same 
distributed tracker.
6. Bots don't have to develop notification tooling and can concentrate 
on just creating and pushing new bugs. This lowers the entry barrier if 
new bots are developed.

It's entirely possible that git-bug is the wrong tool for this -- and, 
in fact, it's easy to argue that git is the wrong tool for this and what 
git-bug is doing to twist git to suit its purposes is wrong and 
horrible. Some would argue that blockchains were envisioned for exactly 
this purpose, except that blockchain as a technology is currently in the 
"sardonically cringe whenever someone mentions it" stage of adoption 
(especially every time bitcoin drops a few thousand points).

In general, I believe that we should be aiming to develop tools that are 
git-like in the sense that they do not depend on a centralized entity.  
For the longest time, the distributed nature of email was what made it 
possible for Linux development to remain truly decentralized, but email 
in 2019 is radically different from email in 2009. Running an 
independent email server that reliably sends and receives email is 
becoming more and more difficult now that most of email traffic goes 
through 5-6 major companies -- you must do SPF, DKIM, ARC/DMARC, TLS, 
and who knows what next, just to be reliably accepted by Gmail (maybe).  
And even if someone uses one of those major email providers doesn't mean 
the patches won't end up in someone's spam folder, show up a week late, 
or arrive mangled.

Public-inbox makes this situation a bit better, but it still relies on 
email remaining generally functional. My hope it that we'll be able to 
take this a step further and create truly distributed alternatives to 
platforms like Github/Gitlab that wouldn't require using centralized 
resources for bug tracking and CI. We've done this for source code with 
git, and we should aim to do the same for the rest.

-K