[PATCH 0/2] btrfs-progs: Introduce devel namespace

[PATCH 0/2] btrfs-progs: Introduce devel namespace

[David Sterba]

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

[PATCH 1/2] btrfs-progs: introduce command namespace for development features

[David Sterba]

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.

Signed-off-by: David Sterba <dsterba@suse.cz>
---
 btrfs.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/btrfs.c b/btrfs.c
index 4e93e13..dff0d70 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -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

Re: [PATCH 1/2] btrfs-progs: introduce command namespace for development features

[Zach Brown]

On Tue, Aug 06, 2013 at 02:25:20PM +0200, David Sterba wrote:
> 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.

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

Re: [PATCH 1/2] btrfs-progs: introduce command namespace for development features

[Anand Jain]

  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


On 08/07/2013 02:01 AM, Zach Brown wrote:
> On Tue, Aug 06, 2013 at 02:25:20PM +0200, David Sterba wrote:
>> 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.
>
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH 1/2] btrfs-progs: introduce command namespace for development features

[David Sterba]

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

Re: [PATCH 1/2] btrfs-progs: introduce command namespace for development features

[David Sterba]

On Wed, Aug 07, 2013 at 01:26:58PM +0200, David Sterba wrote:
> 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.

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

Re: [PATCH 1/2] btrfs-progs: introduce command namespace for development features

[Zach Brown]

On Wed, Aug 07, 2013 at 02:38:12PM +0200, David Sterba wrote:
> On Wed, Aug 07, 2013 at 01:26:58PM +0200, David Sterba wrote:
> > 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.
> 
> ... 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

[PATCH 2/2] btrfs-progs: move chunk-recover command to devel namespace

[David Sterba]

Signed-off-by: David Sterba <dsterba@suse.cz>
---
 btrfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/btrfs.c b/btrfs.c
index dff0d70..4bbce48 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -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