On 2016-02-04 15:40, Moviuro wrote:
On Thu, Feb 4, 2016 at 9:28 PM Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
On 2016-02-04 14:40, Chris Murphy wrote:
On Thu, Feb 4, 2016 at 5:53 AM, Austin S. Hemmelgarn
<ahferro...@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.
--
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
