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

quoted text
> > > 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.

quoted text
> 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.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/