On Wed, Apr 02, 2014 at 10:26:20AM -0400, Theodore Ts'o wrote: > On Wed, Apr 02, 2014 at 09:28:23AM +1100, Dave Chinner wrote: > > > And of course, whether changes in the mainline kernel tree are > > > manually propagated changes from the xfstests.git tree, or whether > > > primary development happens in the kernel tree, is ultimately going to > > > be up to you and the XFS developers who have stewardship of xfstests. > > > I'm not sure I would be that excited about manual propagation of > > > changes from one git tree to another, but that is of course, up to > > > you. > > > > And this is exactly my point, Ted. Again, you are presuming that the > > implementation is going to require syncing commits across disparate > > git trees and other such games will be needed to maintain separate > > packages. Nothing could be further from the truth: we already have > > this problem with the shared XFS kernel/userspace code and it's a > > royal PITA keeping them in sync. Hence introducing the same > > maintenance problem with new code and infrastructure is highly > > undesirable and something we'll try to avoid at all costs. > > Actually, I was presuming that the thing that makes the most sense was > to move all or most of the tests in xfstests into the kernel tests > tree. And then you complained that I was making a presumption that > this was the only sane thing to do. That's why I said, "if you want > to do something insane, be my guest". So, you think there's only one "sane" solution. That's a massive assumption, and that's what I'm pointing out. It's perfectly sane to treat the kernel tree as just another downstream consumer of xfstests, and simple add infrastructure to the kernel tree to source and build xfstests from the upstream repo. Indeed, this is the existing model that seems to work for just about everyone, so I see no reason why we should treat Greg's request any differently. IOWs, you're assumming that the only thing that makes sense is that "kernel tree == upstream". We don't push code into the kernel tree just because it's the Kernel Tree. We push code there if it makes sense to do so - either from a commercial or technical PO. We have no commercial motive to move xfstests into the kernel tree, and I see a lot technical downsides to moving xfstests in it's entirity to the kernel tree. So, really, putting some infrastructure into the kernel tree to use xfstests (i.e. a downstream consumer) makes a lot more sense from a technical point of view than making the kernel tree the xfstests upstream. It's a sane way to solve the problem that Greg wanted solved - the kernel tree carries the infrastructure needed to solve the "test in place" use case that -stable maintainers want, but it doesn't turn test development nor filesystem developer work flows on their head nor make xfstests less useful to existing users. > I have nothing against doing a formal requirements process, that's I'm not doing anything formal, just doing the right thing to make sure we don't do all the work and then be told "not acceptable".... > fine, but I think there are certain things about what the final > solution of "test in the kernel git tree" will look like that are > pretty obvious. Certain things, yes. Like using kvm to run the tests in a container. Just what form that takes is not clear right now... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
