[TOPIC] scsi-queue tree past and future

[TOPIC] scsi-queue tree past and future

[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.

Re: [TOPIC] scsi-queue tree past and future

[James Bottomley]

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

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

Re: [Lsf] [TOPIC] scsi-queue tree past and future

[Sagi Grimberg]

On 3/5/2015 3:31 PM, 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.

+1

I think this approach can make a lot of sense for other subsystems as
well.

Sagi.

Re: [Lsf] [TOPIC] scsi-queue tree past and future

[Davidlohr Bueso]

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.

Thanks,
Davidlohr

Re: [Lsf] [TOPIC] scsi-queue tree past and future

[James Bottomley]

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

Re: [Lsf] [TOPIC] scsi-queue tree past and future

[Davidlohr Bueso]

On Fri, 2015-03-06 at 20:43 -0800, James Bottomley wrote:
> 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.

> 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

Re: [TOPIC] scsi-queue tree past and future

[Tomas Henzl]

On 03/05/2015 02:31 PM, 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.

>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

>
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html