All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Moviuro <moviuro@gmail.com>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs-progs and btrfs(8) inconsistencies
Date: Thu, 4 Feb 2016 17:15:06 +0800	[thread overview]
Message-ID: <56B3169A.10508@cn.fujitsu.com> (raw)
In-Reply-To: <CAM=f9=X5BU0N4iueXtVf4y5SAxrnMQgtgbrsx0Gbc8W6SEspMg@mail.gmail.com>



Moviuro wrote on 2016/02/04 09:57 +0100:
> On Thu, Feb 4, 2016 at 2:33 AM, Qu Wenruo <quwenruo@cn.fujitsu.com> wrote:
>>
>>
>> Moviuro wrote on 2016/02/03 22:54 +0100:
>>>
>>> Hi all,
>>>
>>> ...
>>>
>>> # btrfs subvolume create foo # should be silent
>>> # btrfs subvolume create -v foo
>>> /absolute/path/foo
>>> # btrfs subvolume create [--details|-vv] foo
>>> PATH:/absolute/path/foo
>>> UUID:082df386-98c2-44d9-9012-07fb2b22ea20
>>> [And whatnot]
>>
>>
>> The idea itself makes a lot of sense.
>> But I have at least two things to worry about:
>>
>> 1) Old scripts backward compatibility
>>     Especially xfstests. Maintainer will hate it a lot.
>>     As we have changed it several times and broken existing test cases.
> Right now, I can think of the following:
> - add a "backward-compatibility switch", like -o|--old, which would
> have no effect on the output on version 4.X.
> - add a "use the new behavior switch", like -n|--new, which would have
> no effect starting with the next big release (5.X)
>
>>     Although personally I like to let all the backward compatibility
>>     things go hell, but that's definitely not how things work. :(
>>
>> 2) End-user taste.
>>     Some end-users like such info as feedback of success.
>>     Of course other users like it act as silent as possible.
> I'm pretty sure that's... not the case. Almost everything on GNU/Linux
> is silent. cd(1) is silent, cp(1) is silent, rm(1)...
> What they all have though is a -v|--verbose switch.
>
>>>
>>> That's a first example. Same should go for all the commands. I have no
>>> idea
>>> how/where we could share about good/bad outputs (Google Drive? Framapad?
>>> git[hub|lab]?)
>>
>>
>> Maybe it's overkilling, but I like the idea to have a good example about how
>> CLI interface should be designed.
>> But it may be harder for all developer/reviewer to follow that restrict
>> example.
>>
>> And even more, I hope there will be a nice btrfs-progs CLI design guideline.
>> (Although it's surely overkilling)
> What kind of format do you think we should write this in? drop a
> stylesheet.md in the repo?

Markdown is good enough for me.
But I'm not sure where to put it.
Btrfs wiki? Btrfs-progs repo?

Maybe you can write one and put it in btrfs-progs, and send out as a 
patch for us to review?

Thanks,
Qu

>
>> Thanks,
>> Qu
>>> Then come inconsistencies: compare the outputs of
>>> ...
>>
>
>



  reply	other threads:[~2016-02-04  9:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03 21:54 btrfs-progs and btrfs(8) inconsistencies Moviuro
2016-02-04  1:33 ` Qu Wenruo
2016-02-04  8:57   ` Moviuro
2016-02-04  9:15     ` Qu Wenruo [this message]
2016-02-04 10:14     ` Martin Steigerwald
2016-02-04 12:04       ` Moviuro
2016-02-04 12:53       ` Austin S. Hemmelgarn
2016-02-04 19:40         ` Chris Murphy
2016-02-04 20:19           ` Austin S. Hemmelgarn
2016-02-04 20:40             ` Moviuro
2016-02-05 13:04               ` Austin S. Hemmelgarn
2016-02-04 17:17   ` Goffredo Baroncelli
2016-02-04 19:48     ` Hugo Mills
2016-02-04 20:10     ` Chris Murphy
2016-02-04 18:22 ` Chris Murphy
2016-02-05  3:11 ` Anand Jain
2016-02-05 12:59   ` Austin S. Hemmelgarn
2016-02-06 21:35   ` Chris Murphy
2016-02-07 10:07   ` Qu Wenruo
2016-02-07 20:26     ` Goffredo Baroncelli
2016-03-08 16:02 ` David Sterba
2016-03-09 10:02   ` Moviuro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56B3169A.10508@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=moviuro@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.