netdev - Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20171029.104541.1487088453362795756.davem@davemloft.net>
Date:   Sun, 29 Oct 2017 10:45:41 +0900 (KST)
From:   David Miller <davem@...emloft.net>
To:     linux-hams@...nnet.net
Cc:     garsilva@...eddedor.com, linux-hams@...r.kernel.org,
        netdev@...r.kernel.org, ralf@...ux-mips.org, wharms@....de,
        hal@...net.au, f6bvp@...e.fr, thomas@...erried.de
Subject: Re: [PATCH v3 0/2] refactor code and mark expected switch
 fall-throughs

From: David Ranch <linux-hams@...nnet.net>
Date: Sat, 28 Oct 2017 10:53:24 -0700

> Does anyone else have thoughts on this topic?

I think you are making a mountain out of a mole hill.

If you care so much about this, set things up so that entities such as
the kbuild test robot run whatever tests you think are necessary.

Otherwise, continually test the stack yourself and report any
regressions here as fast as you can.

If soemone can't be bothered to verify or test someone's change in 2
or 3 days, except in extreme circumstances, I absolutely refuse to
burdon the submitter and let their patches rot in the queue.

That's unacceptable.

That's the proper way to deal with this, without unreasonably
burdoning people who just want to keep the code across the tree modern
and more up to date.

Thank you.