On Fri, Jun 21, 2013 at 09:40:43AM +0800, Andy Green wrote:
On 21 June 2013 00:22, Mark Brown broonie@linaro.org wrote:
It's important to follow good practice here; it helps set a good example for people of upstream processes.
Unless I use my phone, the last 10+ years my mail is all inline reply. This last week I have to use gmail interface for the first time.
You can actually do inline replies with gmail, it just doesn't encourage it - click on the [...] and it'll expand the quoted mail in an editable format.
So, my previous job was all about shipping into smartphones so I'm more than familiar with the situation here - this is in no way specific to Linaro, it's a pressure felt by everyone shipping into the consumer electronics space. To me part of teaching people about the value of upstreaming is teaching them how that process interacts with and helps the process of stabalisation for release.
This kind of assumes the Landing Teams are in a position where people are interested in their "teachings". More often someone in higher management has realized that the LT can do them a lot of good, but on the ground that's not always understood. If the company in question has established fiefdoms, it can get difficult even reaching agreement on LT necessities like having a rebase tree (the otherwise excellent Felipe Balbi at a member gave me a nice lecture about his certainties we should use history trees, because the reasoning was outside his experience).
Of course, I'm not saying that this is a trivial thing to sell but that doesn't mean we shouldn't be pushing it. If it reall was trivially obvious probably everyone would be doing it already :)
Anyway the point is we're used to people explaining to use what we should do and how to do it when they don't understand the relationship with the member. We are definitely motivated to do the Right Thing if we look glum as we appear to be doing the wrong thing it may be because there's nothing we can do about it.
Sure, and doing and talking are obviously different. One thing that can sometimes be done in that situation is to do the upstreaming thing on anything that's already upstream, though obviously that's not an option in many cases.
As I said before this issue isn't necessarily your problem but because the TSC is controlled by members, what you may get asked to do is unbounded in fact. What I'm suggesting is if you see a real piece of madness coming, please push back. Some mixtures of LTS base version and backport request will get asked in order to avoid the work they ought to be doing to base on a later kernel; that work then and the retardation of alignment of the member with upstream can be bad news. Consider for example 3.0 basis and big.LITTLE backport. Maybe if you start from 3.9 or other modern basis and v8 support is already started in there, the worst kind of thing won't happen any more, in which case great.
I think you know me well enough to realise that I will do that, and certainly the current requests are all for relatively modern kernels. Like I say the pressure generated by Android has been really helpful here, it creates a lot of costs for people trying to avoid moving forwards.
Sure, it's not ideal and one of the things you guys on the landing teams need to be teaching people is how to do this effectively. The issue
As I explained above, even though the member pays for the LT it does not mean that the various parts of the member which may be under a different management structure than called us in, will listen to us. We also met characters who prioritized upstreaming over servicing the member's customers at all, which is a different form of getting it fatally wrong.
I appreciate this and I do think this isn't work solely for the landing teams - there's a non-technical side here as well for example.
Essentially everyone in the Android space will be working on v3.4 up until the release of Key Lime Pie. That's the stable kernel for Jelly Bean, that's what everyone works with. For ICS it was v3.0, though that's pretty much dead at this point for anything except support.
Not in "some" companies: it's still alive and getting new engineering work done on it, despite it being explained it's like giving birth to old men. For the people who think that's OK, I'm worrying the LTS kernel will allow them to argue for that approach.
Our current plan of record is to taper off new features after a year so hopefully there's at least some back pressure there.
As far as device tree goes... it's not really solving a problem that people doing phones have. People will use it (and IME do use it) when
However the code we have seen from vendor suppliers for drivers is really nasty in many cases. It's quite normal to embed physical addresses and IRQs direct in the driver code, we even got one where they had put Samsung pre-generic gpio gpio api usage right in there (the driver is nothing Samsung specific). Even Mali has that kind of stuff piled in there. So even for phones DT will be very valuable (and I noticed yesterday, Chromebook kernels have DT attached to kernel binary). It is expensive running around dealing with and maintaining that.
Note however that the Chromebooks aren't fully supported with only DT yet - we still need to work out how to handle things like the WiFi reset. As far as the code quality thing goes my experience is that DT will just push around the quality issues, it won't stop them (as you'd expect really).
I agree with what you're saying they don't feel that yet and there's no DT backport pressure, it's because they are used to one kernel per product and wasting time running around the code meddling as a one-off, rather than one kernel per member and CONFIG_ARCH_MULTIPLATFORM / DT and do the work once.
That's not really it - the trick is to keep the active parts of the code in sync with each other to minimise redundant development and there's other ways of doing that than doing a single binary for multiple boards that people have already figured out. By the time you get to actually shipping most of the effort is on QA anyway which for thoroughness needs to be on a per system basis.
He mentioned that the Andriodization patches are in LTS already... what I was initially talking about is how to make sure llct merged content is still there if we later switch our LT kernel to use LTS basis. So if he added a pending series about xyz subsystem to llct for 3.x, it's arguable to expect that the accepted series for xyz subsystem appear in some downstream version of LTS for 3.x, even if it was accepted after 3.x.
That's what we'll be going for for for anything which is included in LTS, though that won't be absolutely everything that is being done within Linaro.
As I said that's probably not your problem, it's something Andrey could take care of doing on top of your mainline-only core LTS branch, but there needs to be a discussion about if we even want that, or if content added at llct just stops at llct and your mainline-only core LTS branch is all there is.
I suspect the backports will be too much effort there for anything with non-trivial invasiveness and that people might want the support. From an encouraging people to upstream point of view it does also seem like we should have some barriers on the backports, to a certain extent what