On Fri, 2015-03-06 at 20:22 -0800, Davidlohr Bueso wrote: > On Thu, 2015-03-05 at 06:48 -0800, James Bottomley wrote: > > On Thu, 2015-03-05 at 14:31 +0100, Christoph Hellwig wrote: > > > For about 8 month I've merged almost every scsi commit through the > > > scsi-queue staging tree, and it seems to have worked out well enough. > > > > > > I've been too busy for the next cycle, so 4.1 will probably have to live > > > without it. I'd like to get feedback on how the tree worked for contributors > > > and driver maintainers, and brainstorm how to move forward with it, preferably > > > some form of real team maintainance that avoids single points of failure. > > > > I'd like to thank Christoph for doing this, it's been an enormous help. > > > > Here's what we'll do for 4.1: I need all the current Maintainers to > > collect the patches and reviews in their area and send them to the list > > as a series. We'll be adhering to the guidelines Christoph laid down > > for inclusion: > > > > - the patch needs at least two positive reviews (non-author signoff, > > reviewed-by or acked-by tags). In practice this means it had at > > least one and I added another one. > > As an exception I also take trivial and important fixes if they > > only have a Tested-by: instead of a second review. > > - the patch has no negative review on the mailing list > > - the patch applies cleanly > > - the patch compiles (drivers for architectures I can't test excluded) > > - for core the core branch: the patch survives a full xfstests run > > This should be pretty standard in all subsystems, no? And I know this > has been discussed many times, but I see no reason not to also consider > trinity -- which has a tendency of kicking you in the nuts when you > least expect it to. At least in MM we are trying to be a bit more > proactive about this, perhaps Sasha or Dave would disagree with me ;) > But in general it would also help other subsystems. Well, to clarify what's happening: I'm not running the tests, I asked the 0 day kernel testing project to run them on all the patches in my tree. The 0 day project has a bunch of standard tests for all trees and then some optional ones (like xfstests) which I asked Fengguang to turn on in our case. Trinity is part of the 0 day project tests, so I could ask for it to be turned on too, but I'm not sure it would be so useful for SCSI: trinity is a sys call fuzzing tool but the sys call exposure of SCSI is pretty tiny. xfstests, which exercise the filesystem data above us provide a much wider range of testing. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
