User: Password:
|
|
Subscribe / Log in / New account

Upstream first policy

Upstream first policy

Posted Jun 3, 2010 11:35 UTC (Thu) by epa (subscriber, #39769)
In reply to: Upstream first policy by neilbrown
Parent article: A suspend blockers post-mortem

Maintainability is much more important that functionality.
To whom? Not to the users. Who is the development process intended to benefit?


(Log in to post comments)

Upstream first policy

Posted Jun 3, 2010 12:56 UTC (Thu) by corbet (editor, #1) [Link]

Yes it's important to the users...unless you assume that all of those users want to be running something other than Linux in five years. Without a focus on maintainability you will shortly have a kernel which nobody wants to run.

Upstream first policy

Posted Jun 3, 2010 13:20 UTC (Thu) by michel (subscriber, #10186) [Link]

Not sure who you consider the user in this case. If it's google (as the user/consumer of the kernel), I can agree with the comment. If it's a consumer using an android based phone, I think the vast majority of them could care less if it's linux under the hood.

Upstream first policy

Posted Jun 3, 2010 13:42 UTC (Thu) by rvfh (subscriber, #31018) [Link]

Indeed, the user is Google in this case, just like they use Linux in many other places. If Google starts seeing a decline in Linux quality, they will either fork or switch. And to some extend, developing wavelocks behind closed doors could be considered a kind of fork (though on a small scale).

Upstream first policy

Posted Jun 3, 2010 14:41 UTC (Thu) by dgm (subscriber, #49227) [Link]

I bet it would be rather the opposite. If Google starts to see that Linux does not have the _functionality_ they want, they will fork or switch.

Why do you think they are _not_ using some of the BSDs?

Upstream first policy

Posted Jun 3, 2010 15:45 UTC (Thu) by iabervon (subscriber, #722) [Link]

Users actually care a whole lot about maintainability of the code if it affects the quality of the maintenance that gets done. They'll be unhappy if apps they've gotten for their phones start misbehaving when they either upgrade the OS or get a new phone. This comes down to the question of whether the APIs that the apps use can be maintained across changes to the underlying system, and has implications for whether your favorite third-party IM program drains your battery when you're idle online or alternatively stops exchanging audio if you don't touch anything during a voice chat.

If Google's using a design that hasn't passed muster, and they eventually switch to a better design, and the original API bitrots, that ends up impacting users, especially ones who have the idea that they can buy an Android phone with the expectation that any program that they come to like will keep working forever.

Upstream first policy

Posted Jun 3, 2010 14:56 UTC (Thu) by epa (subscriber, #39769) [Link]

Agreed, a focus on maintainability is important. But which is more maintainable? Merging existing, working, widely deployed code - or forcing developers like Google to stay out-of-tree for five years?

My point is that the fact that some code is already being used on millions of devices and works *now* should carry some weight, even in assessing future maintainability. (It's much more likely that little-used features will suffer code rot, no matter what their conceptual purity.) At the moment it appears to get no weight at all.

Upstream first policy

Posted Jun 3, 2010 16:54 UTC (Thu) by cry_regarder (subscriber, #50545) [Link]

Of course it got weight...tons of weight. If it hadn't we wouldn't be talking about this now.

Also, the "millions of devices" is a red herring. It is just a handful of different devices, all of the same class. The kernel developers need a solution that works for a vast range of devices over the long haul.

Upstream first policy

Posted Jun 3, 2010 13:36 UTC (Thu) by neilbrown (subscriber, #359) [Link]

> Who is the development process intended to benefit?

Make no mistake: the development process is intended to benefit the developers.

In the case of Linux, many of the developers are users first, and developers second (I certainly started that way), so as a consequence it ends up being focused on benefiting users too, which is nice.

Upstream first policy

Posted Jun 3, 2010 14:08 UTC (Thu) by faramir (subscriber, #2327) [Link]

>In the case of Linux, many of the developers are users first, and >developers second (I certainly started that way), so as a consequence it >ends up being focused on benefiting users too, which is nice.

Depending on how you define it, that should read "benefiting A FEW users".

Between Tivos, WRT54g routers, Android phones, some TVs, and a host of similar products; I suspect that the vast majority of users are not developers of any sort. In most cases, the manufacturers of those products discourage development as well (Android is obviously different).

As has already been stated elsewhere, these users usually neither know nor care that Linux is involved. That doesn't mean that kernel policy (to the extent it exists) should change. But lets be honest here, this is about certain kinds of developers not users.

If one is a developer of an appliance type product, there would appear to be little reason to even subscribe to LKML let alone be involved in the development process. Your product life cycle is short and chances are that any significant kernel changes that you propose will either take too long or never get accepted.

Upstream first policy

Posted Jun 3, 2010 14:32 UTC (Thu) by corbet (editor, #1) [Link]

If you are the developer of one appliance-type product, then maybe you can ignore the process. However, the life cycle of such products tends not to be very long; soon you'll be developing another one. There comes a point where you can't drag that 2.4.x kernel forward any further; it just won't work on the hardware you're using. So you're stuck with trying to make your stuff work on something newer. And that will be painful.

I've consulted for companies like this. Had they worked with upstream and made sure the stuff they needed got there, they would have found it waiting for them when the time came to move to a newer kernel. Instead, they set themselves up for a bunch of high-intensity, short-deadline pain. That can be lucrative for kernel consultants, but it's not really a good way to run a company.

To me, treating the kernel as a throwaway resource doesn't make sense even for the most myopic of embedded systems developers. Unless they plan to go out of business soon, they will want a maintainable kernel five or ten years down the road, and they will want it to meet their particular needs. And that doesn't just happen by chance.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds