btrfs-progs: Introduce devel namespace

Add namespace for features under development and the first user.

David Sterba (2):
btrfs-progs: introduce command namespace for development features
btrfs-progs: move chunk-recover command to devel namespace

 btrfs.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

1.8.3.1

We'd like to make it easier to preview a new feature and remove the burden to invent sane user interface (command name, placement, arguments, man) from the beginning. For this purpose the developer are free to use the 1st level namespace called '_'. It will be hidden from regular btrfs help output and the only way to get the commands is

  btrfs _ --help

The commands appear as if they are in the 1st level, but have to be used from inside _, eg.

btrfs _ newcommand

Once the interface is stable, the command will be moved to the right place.

---
 btrfs.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

index 4e93e13..dff0d70 100644
@@ -239,6 +239,28 @@ static int handle_options(int *argc, char ***argv)
 	return (*argv) - orig_argv;
 }
 
+static const char * const devel_features_cmd_usage[] = {
+	"btrfs _ <command> [<args>]",
+	NULL
+};
+
+const struct cmd_group devel_features_cmd_group = {
+	devel_features_cmd_usage,
+	"WARNING: this is a namespace for commands that are in development\n"
+	"and anything is subject to change. Once the user interface gets\n"
+	"stabilized, it'll be moved to the appropriate place.\n"
+	"NOTE: you have to call the commands as eg.\n"
+	"\tbtrfs _ newcommand --args\n",
+	{
+		{ 0, 0, 0, 0, 0 }
+	}
+};
+
+int cmd_devel_features(int argc, char **argv)
+{
+	return handle_command_group(&devel_features_cmd_group, argc, argv);
+}
+
 const struct cmd_group btrfs_cmd_group = {
 	btrfs_cmd_group_usage, btrfs_cmd_group_info, {
 		{ "subvolume", cmd_subvolume, NULL, &subvolume_cmd_group, 0 },

@@ -255,6 +277,8 @@ const struct cmd_group btrfs_cmd_group = {
 		{ "quota", cmd_quota, NULL, &quota_cmd_group, 0 },
 		{ "qgroup", cmd_qgroup, NULL, &qgroup_cmd_group, 0 },
 		{ "replace", cmd_replace, NULL, &replace_cmd_group, 0 },
+		{ "_", cmd_devel_features, devel_features_cmd_usage,
+			&devel_features_cmd_group, 1 },
 		{ "help", cmd_help, cmd_help_usage, NULL, 0 },
 		{ "version", cmd_version, cmd_version_usage, NULL, 0 },
 		{ 0, 0, 0, 0, 0 }

1.8.3.1

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.

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?

- z

Further there is benefit of having newer subcommands in the master branch - it gets visibility.

However if we are trying to solve the problem of it not being end user ready then there can be a warning message about it when the user uses it or sees it.

I see some of online shops tagging new problem with bright red "New" on the product image. Could we have some "warning" shown against these new subcommands ?

just my 1c.

Anand

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.

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

... but then there's no point hiding the commands under _ hmm.

You might not be able to tell from way over there, but I'm making that gesture where you point at your nose to indicate that you understood my point exactly :)

- z

---
 btrfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index dff0d70..4bbce48 100644
@@ -252,6 +252,7 @@ const struct cmd_group devel_features_cmd_group = {
 	"NOTE: you have to call the commands as eg.\n"
 	"\tbtrfs _ newcommand --args\n",
 	{
+		{ "chunk-recover", cmd_chunk_recover, cmd_chunk_recover_usage, NULL, 0},
 		{ 0, 0, 0, 0, 0 }
 	}
 };

@@ -269,7 +270,6 @@ const struct cmd_group btrfs_cmd_group = {
 		{ "device", cmd_device, NULL, &device_cmd_group, 0 },
 		{ "scrub", cmd_scrub, NULL, &scrub_cmd_group, 0 },
 		{ "check", cmd_check, cmd_check_usage, NULL, 0 },
-		{ "chunk-recover", cmd_chunk_recover, cmd_chunk_recover_usage, NULL, 0},
 		{ "restore", cmd_restore, cmd_restore_usage, NULL, 0 },
 		{ "inspect-internal", cmd_inspect, NULL, &inspect_cmd_group, 0 },
 		{ "send", cmd_send, cmd_send_usage, NULL, 0 },

1.8.3.1