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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 26 Oct 2009 23:02:38 -0400
From:	Steven Rostedt <>
To:	David Miller <>
Subject: Re: [RFC] to rebase or not to rebase on linux-next

On Mon, 2009-10-26 at 18:34 -0700, David Miller wrote:

> > My testing is mostly done in Ingo's test suite, and that happens after I
> > do my push to him. This works best for me.
> So you both should keep your trees private until it's all sorted out
> and you have the results in hand.
> Nobody forces you guys to use public trees just to run Ingo's personal
> test suite, you have decided to work that way.  And that is therefore
> something you guys can change without effecting other people.

I guess we have a different point of view on this. We like to keep
things public as much as possible. As stated earlier, it's easier to get
people to test the patches if the git trees in question are available.

90% of the bugs are found by Ingo's tests, the other 10% is found by
people pulling one of our git trees and testing themselves.

> > If I had to publish and let cook on LKML, then I would also need to keep
> > better accounting of what I have pushed out and what I have left to do.
> The problem isn't that you have to push patches out and only work
> with patches, the problem is that you want to use publicly visible
> GIT trees to do your testing at all times.
> And sorry, that is not how you're supposed to do things.

That is a matter of opinion. We prefer to keep things as public as
possible. No patches back and forth privately doing our own internal
test suites, then come out with some "production release". If someone
found something wrong with it then, we would need to start the cycle all
over again.

I do not like to send patches to anyone privately, unless it is a hack
that is to help someone debug something and not for inclusion. Any time
I send out a patch to be included for mainline, I start it out public. I
also prefer to have a public git repo available to be tested by anyone.

Whether I'm sending a patch to Ingo, Linus, Andrew, or even you, I would
do it publicly and have a git repo to pull from for simplicity.

-- Steve

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists