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

[Greg KH <greg@kroah.com>]

On Thu, May 22, 2014 at 08:03:32PM -0700, Dan Williams wrote:
> >> Neil already disabused me of the idea that a "gatekeeper" could be
> >> used to beneficial effect in the core kernel, and I can see it's
> >> equally difficult to use this in filesystems that need to be careful
> >> of ABI changes.  However, nothing presented so far has swayed me from
> >> my top of mind concern which is the ability to ship pre-production
> >> driver features in the upstream kernel. I'm thinking of it as
> >> "-staging for otherwise established drivers".
> >
> > The thing you need to realize is that the large majority of people who
> > would ever use that new "feature" will not until it ends up in an
> > "enterprise" kernel release.  And that will not be for another few
> > years, so while you think you got it all right, we really don't know who
> > is using it, or how well it works, for a few years.
> >
> > But feel free to try to do this in your subsystem, as Ted points out, it
> > can be done for somethings, but be careful about thinking things are ok
> > when you don't have many real users :)
> >
> 
> Point taken.
> 
> However, if this is the case, why is there so much tension around some
> merge events?  Especially in cases where there is low risk for
> regression.

What "tension" are you speaking of?  Getting new apis correct before we
do a release?  Or something else?

I didn't see any specific examples mentioned in this thread, but I might
have missed it.

> We seem to aim for perfection in merging and that is
> specifically the latency I am targeting with a "this feature is behind
> a gatekeeper" release-valve for that pressure to not merge.  If things
> stay behind a gatekeeper too long they get reverted.  Would that
> modulate the latency to "ack" in any meaningful way.

For a filesystem, or a driver, as stated, this might work.  For a
syscall, or new subsystem api to userspace, that isn't going to work for
the above mentioned reasons.  See the cgroups interface for one example
of how long it took for people to actually start to use it (years) and
then, once we realized just how bad the interface really was for
real-world usages, it was too late as people were already using them, so
we have to have them around for an indefinate time before they can be
removed, if ever.

thanks,

greg k-h