On Tue, Aug 06, 2013 at 11:01:37AM -0700, Zach Brown wrote: > My biggest worry about this is that it complicates the coordination of > automated testing, which is already in a terrible state for btrfs-progs. > It can't possibly motivate people to write tests if we make the process > more cumbersome than it already is. > > So we develop tests for a command (maybe in xfstests, maybe in > btrfs-progs) that use this magical _ namespace. Then the command is > merged. When are the tests updated? Do they fallback to both so that > the tests can work across the merge? Do we add some complexity to try > and magically match _ commands that aren't found with matching commands > somewhere else in the heirarchy? Ugh, all 'round.
My motivation is to merge various patchsets into one git tree even if it's not in a final state of development, to let people test use it and give feedback about usability. Patches floating around in the mailinglist get tested by very few people. A test developed for a _ command is unlikely to be merged into xfstests, I expect the test to land there after the command is fininished and has fixed command line UI. In the meantime, the test reflects the _ status of the command. I was thinking about extending xfstests to allow external testscripts to be run as if it were a regular xfstest (using all the infrastructure). That way the test is part of the btrfs-progs patchset and is synchronized with the command name. Once it's done, _ is dropped and test can be submitted to xfstests. > I'm not sure I understand what problem this is really solving. People > shouldn't be expecting to find incomplete features in the master branch, > right? If people are looking to test incomplete work they can get your > integration branch and, well, we don't care if it changes later? Well, I hope no incomplete feature ends up in master, but for example the chunk-recover got merged. Moving the command name is simple, but we want to catch it earlier than when it's too late. I have to re-organize integration branch(es) better, so there is eg. a branch without unstable stuff, possibly always in a pullable state. On top of that a bunch of topic branches with the _ features. Let me know if I missed to answer something important. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
