scsi-queue tree past and future
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.
James Bottomley
maintainerQuoted 7 lines · Christoph Hellwig
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
For the last requirement, the 0 day kernel test project will be checking this. That means negative reports from the 0 day project on a patch will be grounds for removal.
I'll try to curate the patches in areas without maintainers (like the core). Remember, in all cases, you get an email from my automation infrastructure when a patch is added (or removed) from any of the SCSI trees, so if you haven't seen the email, the patch isn't in the tree.
You can also see the state of the git trees here:
http://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/
with the misc branch being for 4.1 and the fixes branch being for 4.0-rc
James
Quoted 16 lines · James Bottomley
Quoted 7 lines · Christoph Hellwig
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:
Quoted 9 lines
- 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.
Thanks,
Davidlohr
James Bottomley
maintainerQuoted 27 lines · Davidlohr Bueso
Quoted 16 lines · James Bottomley
Quoted 7 lines · Christoph Hellwig
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:
Quoted 9 lines
- 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
Quoted 6 lines
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
Quoted 8 lines · James Bottomley
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,
Oh, I was not aware of that. I tend to consider LTP something completely unrelated.
Quoted 4 lines
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.
Yeah I'm really talking at a generic level, just like LTP.
Thanks,
Davidlohr
Quoted 7 lines · Christoph Hellwig
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.
+1
I think this approach can make a lot of sense for other subsystems as well.
Sagi.
Quoted 4 lines · Christoph Hellwig
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.
From my user perspective the scsi-queue was an important help and have been using using
it a lot. I hope it will have a future.
Thanks,
Tomas
Quoted 9 lines
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. --
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html