Re: [Ksummit-discuss] [CORE TOPIC] [nomination] Move Fast and Oops Things

[Dan Williams <dan.j.williams@intel.com>]

[ speaking for myself ]

On Thu, May 15, 2014 at 7:56 PM, NeilBrown <neilb@suse.de> wrote:
> On Thu, 15 May 2014 16:13:58 -0700 Dan Williams <dan.j.williams@gmail.com>
> wrote:
>
>> What would it take and would we even consider moving 2x faster than we
>> are now?
>
> Hi Dan,
>  you seem to be suggesting that there is some limit other than "competent
>  engineering time" which is slowing Linux "progress" down.

Where "progress" is "value delivered to users", yes.

>  Are you really suggesting that?

Yes, look at -staging as the first step down this path.  Functionality
delivered to users while "upstream acceptance" happens in parallel.
I'm arguing for a finer grained mechanism for staging functionality
out to users.

> What might these other limits be?

Testing and audience.  A simplistic example of moving slow is merging
a feature only after it has proven to have a large enough audience.
Or the opposite, spending development resources to polish and merge a
dead-on-arrival solution, but only discovering that fact once exposed
to wider distribution.

>  Certainly there are limits to minimum gap between conceptualisation and
>  release (at least one release cycle), but is there really a limit to the
>  parallelism that can be achieved?

Again, in general, I think there are aspects of "upstream acceptance"
that can done in parallel with delivering value to end users.