On Thu, 7 Feb 2008 13:35:09 -0800 "Stephen Neuendorffer" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
