On Thu, Feb 4, 2016 at 9:28 PM Austin S. Hemmelgarn <ahferroin7@xxxxxxxxx> wrote: > > On 2016-02-04 14:40, Chris Murphy wrote: > > On Thu, Feb 4, 2016 at 5:53 AM, Austin S. Hemmelgarn > > <ahferroin7@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
