On Wed, Apr 16, 2014 at 10:06:35AM +1000, Dave Chinner wrote: > > Some of the work that I've > > been doing with kvm-xfstests and why I created a github tytso/xfstests > > git tree is specifically to make sure things go much more smoothly > > this time around. > > Ted, this looks and sounds like you're preparing to fork xfstests. > Why? What's the problem with working upstream on test development > and refinement like everyone else does? I'd prefer not to fork xfstests. However, I do want to get more ext4 developers using automated xfstests testing, so I can scale better. In order to do that, I need to be able to make it really easy for people to who aren't hard-core xfstests people to be able to use it. One of the nice things about kvm-xfstests is that a *lot* easier for people to figure out how to use it. If I can lower the activation energy required to get people to use xfstests, it saves me time in the end. The reason why I created the github repository is because if I'm going to be shipping a KVM test appliance image that people can use in a turn-key environment, I'd prefer that all of the sources, including any local changes that I might need to make the tests run as smoothly as possible, are available in a public repository. (And at one point, I did have up to 12 local changes, which is why I wanted it tracked in a repo.) Every single local change I made was either a test or commit that hadn't been accepted into the upstream xfstests repository yet, or a fix I wrote that I sent upstream. And as soon as the fixes made it into the upstream xfstests repository, I rebased them away. At the moment, there's only once commit in my xfstests github repository which isn't upstream and it's the: check: add support for an external file containing tests to exclude commit for which I've sent the V2 version to you. So for the most part, I want to keep the repo as close to upstream as possible, and ideally identical to upstream, and I've been working towards that end. > This thread is a demonstration of how avoiding upstream interaction > results in nasty hacks being proposed. If you asked the question on > the xfs mailing list of how to avoid various fsstress/fsx > operations, we woul dhave told you that using FSSTRESS_AVOID and > adding an equivalent FSX_AVOID to xfstests is all that is needed. > i.e. we already have partial infrastructure support for what you > need in xfstests and it would be about 30 minutes work to add > FSX_AVOID.... > > Is that fast enough for you? > > Indeed, we could also use similar env vars to ensure various > _requires_* checks fail and to populate FSSTRESS_AVOID/FSX_AVOID > automatically and so tests that require this functionality are not > run. Well, it took me about 1 minute to write the dozen line kernel patch. I really didn't want to ask you to make changes to xfstests for me, but if you're willing to make those changes, that would be great. I really didn't want to presume, though. And if the answer is that I need to spend the time making all of these changes --- I'll try, but if I don't have time, I may end up taking the more expedient path. > IOWs, it's in your best interests to work with upstream to add the > functionality you require to xfstests. History tells us that forking > development into private repositories has never worked out well for > anyone, so I'd really, really like you to *at least try* to work > with upstream as your primary test development environment.... As I said, every single patch which I put in my local xfstests tree I also sent upstream. That being said, I wasn't sure whether you were going to accept that last change, since there was similar, but for me, not usable functionality in the form of the -X option. So if you weren't going to accept a change to allow the excluded list of tests to be kept in a single file outside of the tests/* subdirectory, I probably would have carried it as a separate patch --- because it's something I need, and the current -X functionality really isn't easy to maintain (you need to have many more files, and they have to be dropped into the xfstests tests/* subdirectory). I know that you and I haven't seen eye to eye in the past. For example, the NO_HIDE_STALE out of tree patch which is running on thousands and thousands numbers of machines inside Google, but which the XFS folks have considered evil incarnate. I will freely admit that I'm much more of a pragmatist and much less of a purist on certain matters. So sure, I'm certainly going to _try_ to work with upstream xfstests. I've done that to date. But I'm certainly not going to presume that you're going to like or accept all of the changes I might want to propose. Regards, - Ted _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
