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
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
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
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 n
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 coordina
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
