lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 17 Aug 2011 10:33:05 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Greg KH <greg@...ah.com>, Tim Bird <tbird20d@...il.com>,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	stable-review@...nel.org, stable@...nel.org, tim.bird@...sony.com,
	Arve Hjønnevå <arve@...roid.com>
Subject: Re: Future of the -longterm kernel releases (i.e. how we pick them).

On Wed, Aug 17, 2011 at 6:21 AM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Tue, Aug 16, 2011 at 09:58:56PM -0700, Greg KH wrote:
>> On Tue, Aug 16, 2011 at 04:01:57PM -0700, Tim Bird wrote:
>
>> > The other major out-of-tree patches we usually integrate are
>> > 1) Android
>
>> I would love to get some feedback/contacts with the Android teams to
>> talk about this with them.  If anyone knows anyone I should talk to
>> here, please let me know.
>
> Brian Swetland and Arve Hjønnevåg should be able to point you at the
> right people if they aren't themselves the right people.
>
> [Sorry if my software has mangled your name Arve]

(something ate the final 'g' (fixed above) but otherwise his name
seems to have survived)

As far as long-term kernels goes, from the Android perspective we
strongly prefer to snap up to the most recent released kernel on every
platform/device release.  I prefer to be as up to date on bugfixes and
features from mainline as possible and minimize the deltas on our
stack 'o patches as much as possible.

We've been getting more aggressive about merging in the -rc#s and then
rebasing on the final during development (before final stabilization
freeze for a release) in the last year or so, and it seems to work
pretty well.

Not all OEMs or silicon vendors are as comfortable with this approach
and I expect some would welcome a long term tree they can count on to
get critical fixes for, though.  Device release teams (even our own,
for lead devices we work on) are notoriously risk-averse (often for
good reasons), and tend to get really nervous when they see the total
change count or diff stat for pulling up to a new kernel release close
to "final rom" for a product.

Brian

(apologies to anyone who got this twice, gmail snafu with html
formatted email. I should use mutt for lkml...)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ