Re: btrfs-progs and btrfs(8) inconsistencies

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2016-02-04 15:40, Moviuro wrote:
> On Thu, Feb 4, 2016 at 9:28 PM Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>>
>> On 2016-02-04 14:40, Chris Murphy wrote:
>>> On Thu, Feb 4, 2016 at 5:53 AM, Austin S. Hemmelgarn
>>> <ahferroin7@gmail.com> wrote:
>>>
>>>
>>>> 4) Possibly get rid of the message on subvolume delete (It provides no
>>>> useful information at all, and it has no option to not error out on non
>>>> existence of a subvolume.  In addition, the same arguments as for create
>>>> apply here too.).
>>>
>>> btrfs sub del has different commit modes that affect the user space
>>> command's completion behavior, and output. So I wouldn't say it isn't
>>> useful.
>>>
>> Last I checked, those are controlled by using command line switches,
>> which means that anyone invoking them knows what they're invoking
>> because it's specified on the command line, therefore all info it
>> currently provides in the non-error case is info you should already
>> have.  I have no issue with it spitting out errors if something goes
>> wrong, but it's just annoying having output that provides no information
>> that isn't already known when everything goes right (think atd, cron,
>> and almost any other periodic or deferred scheduling system).
>
> OK, so let's put our thinking into words.
> But where do we start? the ML won't be a good place to do that IMHO.
> Something like github may be easier to contribute to, and since it
> won't be any real code at first, it shouldn't be a problem using a
> platform like that, right? https://github.com/btrfs8-revamp
> If you don't find that to be a good choice, I'm open to alternatives.
>
For the spec itself, I think Github is a good idea.  But I feel we need 
to get actual user input before we start writing the spec.  One of the 
worst things these days about UI design is that quite often the 
designers get no actual user input until after they finalize the design, 
and I would _really_ like to avoid that happening, because when it 
happens it often either kills a project, or makes it so difficult to use 
that people don't want to use it outside of a pre-built system.