linux-kernel - Re: Xilinx: hwicap driver comments

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20080207135341.04e5652a.akpm@linux-foundation.org>
Date:	Thu, 7 Feb 2008 13:53:41 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"Stephen Neuendorffer" <stephen.neuendorffer@...inx.com>
Cc:	grant.likely@...retlab.ca, jirislaby@...il.com,
	linux-kernel@...r.kernel.org, paulus@...ba.org,
	galak@...e.crashing.org, benh@...nel.crashing.org,
	torvalds@...ux-foundation.org
Subject: Re: Xilinx: hwicap driver comments

On Thu, 7 Feb 2008 13:35:09 -0800
"Stephen Neuendorffer" <stephen.neuendorffer@...inx.com> wrote:

> > > It seems wrong that the signoff trail for that patch didn't actually
> > > reflect reality - it should have had both Josh's and Paul's
> signoffs.  That
> > > would require that the changelog be altered during git->git
> transfers which
> > > I expect is just incompatible with the way git works (as far as I
> dimly
> > > understand it).
> 
> I'm rather new to all this and still (to some extent) trying to figure
> out what is expected.

We're all still trying to figure it out, really.  We've gone and made it
awfully easy to get code into the kernel nowadays.  Perhaps too easy.  I'm
presently having a little campaign of watching what's going on a bit more
closely, and ecouraging people to make it easier for others to see what's
going on, should they choose to do so.

I'm hoping that by the time we're developing 2.6.26 there will be a unified
git tree (aka linux-next) (basically all the git and quilt trees from -mm)
for people to look at and play with.  That'll improve our pre-merge test
coverage, but won't do much to improve review.  And it won't do anything to
improve our post-merge bugfixing.

> Maybe what is needed is git pull --ack?

I'm also hoping/expecting/planning that if someone tries to merge a patch
into mainline, and that patch hasn't been in linux-next for "long enough",
flags will wave and lights will flash and we can get to take a closer look
at why it was so late and whether it's OK.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/