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: <20241024054909.49ae9faa@rorschach.local.home>
Date: Thu, 24 Oct 2024 05:49:09 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, Guenter Roeck
 <linux@...ck-us.net>, Michael Ellerman <mpe@...erman.id.au>, Kees Cook
 <kees@...nel.org>, Sasha Levin <sashal@...nel.org>,
 torvalds@...ux-foundation.org, ksummit@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: linus-next: improving functional testing for to-be-merged pull
 requests

On Thu, 24 Oct 2024 02:24:53 -0700
Christoph Hellwig <hch@...radead.org> wrote:

> On Thu, Oct 24, 2024 at 05:21:39AM -0400, Steven Rostedt wrote:
> > them as small as possible. That's not always the case, so maybe I could
> > push it. But it will change my workflow quite a bit or burden Stephen
> > with broken branches.
> > 
> > I'm still not convinced it's worth it.
> > 
> > We are not talking about new development code. We are talking about bug
> > fixes for code that is in Linus's tree. The zero day bot and my tests
> > appear to find most issues. Bugs that happened on my fixes patches are
> > usually other use cases. For instance, cpu hotplug while tracing from
> > rtla. That's not coverage I get from linux-next.  
> 
> Seriously, just add your damn fixes tree to linux-next.  If your fixes
> are as perfect as you claim that one time setup is all you need to do,
> and you have less work than you spent arguing on this thread already.
> 
> If it catches bugs eventually you will need to do more work, but save
> others from deadling with your regression.  There is no downside for
> you.

So basically, all I need to do to satisfy your request is to add fixes
branch that I push to that is pushed after it passes my tests (and not
the urgent branch that is still being tested and may have bugs) and
then have that be added to linux-next?

Now I have been batching changes and not send a pull request right
after my tests pass. I've been sending a pull request at most now once
a week. So I could have this branch hold the code that's already been
tested.

-- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ