Re: [Ksummit-discuss] [Stable kernel] feature backporting collaboration

[Theodore Ts'o <tytso@mit.edu>]

On Wed, Sep 21, 2016 at 07:22:04PM +0100, Mark Brown wrote:
> One problem that bites people fairly hard trying to do upstream first is
> that upstream turns too slowly to do things for the current product in
> some markets, when I was working on phones it'd off the top of my head
> typically be 3-4 months before anything ended up in a release (depending
> on where we were in the release cycle) and another year or so before
> that filtered back out into product (and this is mostly with very low
> resistance subsystems where I'm the maintainer).

To me, "upstream first" doesn't mean wait for things to cycle out to a
release.  It means "develop first on upstream" and then backport to
your product kernel.  And I tend to think of this as something that
should be done on a per-feature or per-device driver basis.  So yes,
your product won't run on upstream, at least certainly not at launch time.

But this tends to avoid a huge build-up of horrific technical debt
where you have a completely horrific scheduler change that is
completely invasive to the core kernel structures, and guarantees that
your changes will break the kernel building on any other architecture.
Most of the time, the comments that you will get back from the
community are actually good ideas; not just nit-picking to slow you
down.  (And, if you know that your changes are going upstream, this
tends to invoke a bit more professional pride with the result that
what you put forward for external review, and what shows up in the
product kernel, isn't a terrible hack filled with techincal debt.)

> When I talk to people about this I tend to talk about doing upstream
> simultaneously rather than first, that is a lot more tractable.  Work on
> things, try to push your latest work upstream as you write it and
> incorporate review feedback from upstream into your product as you go
> but don't gate things on upstream.  Try to view anything that's still in
> review as a problem that needs to be fixed but acknowledge that there's
> also a need to actually get product out the door.

Sure.  I tend to think of that as upstream first, although if people
are happier calling it "upstream simultaneously", the terminology
doesn't really matter all that much.

What *does* matter is an attitude that the goal should be to have
stuff in your product kernel which is upstreamable as the default
goal, and having things that are out-of-tree should be the exception
and not the rule.  And if it does happen, there ought to be good
reasons for each of those changes, and an acknowledgement that
out-of-tree changes represent technical debt.

> People aren't just ignoring the idea of working upstream entirely.
> People are doing work here, it's producing results (or at least a pile
> of mainline code).  Some are doing more than others, some are more
> successful than others but there is a lot happening here.  There's a lot
> of things going on that I'm critical of but there's also a lot of
> perfectly rational, practical decisions being made.  Getting the more
> complex consumer electronics devices to the point where they work as
> well upstream as servers do is not trivial and will take some time.

Perhaps those that are doing good work here should be called out and
given praise?  While there are some negative consequences with calling
out those folks who aren't willing to do more, highlighting the people
who are doing a good job should be all upside.

    	      	     	 	       - Ted