cupcake kernel version

[Dan Raaka]

Please confirm what version of kernel will be in cupcake FC?

The cupcake preview SDK seems to contain 2.6.27, but there are
references to even 2.6.30 on the gitweb
http://android.git.kernel.org/?p=kernel/msm.git;a=summary

-Dan

[Mike Lockwood]

Cupcake is using the 2.6.27 kernel. We are planning on moving to
2.6.29 for the next release (donut).

Mike

--
Mike Lockwood
Google android team

[Jerry Jih]

Dear Mike,

 

1. How about the release schedule of Donut?

2. How about the major difference between Cupcake and Donut? (WVGA, AGPS, ...)

3. Any impact for CTS and GMS if using Cupcake?

 

Jerry

2009/4/23 Mike Lockwood <lock...@android.com>

[Mike Lockwood]

Hi Jerry,

We don't have a final schedule for donut yet. Cupcake has some
limited support for AGPS (using the SUPL support in the Qualcomm
chipset in the G1). This support will be improved in the donut
release. I'm not sure what the status is for WVGA, CTS and GMS.

Mike

[Dianne Hackborn]

As always, the current roadmap is here:

http://source.android.com/roadmap

I realize this doesn't provide much detail, but at this point we really don't want to be in the position of making even implied commitments that people are then going to base device schedules around when we are not confident enough about them.

On Wed, Apr 22, 2009 at 11:57 PM, Jerry Jih <jjih...@gmail.com> wrote:

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Disconnect]

So AOSP will continue to be driven by closed source requirements at least through donut? Thats unencouraging.

[Mike Lockwood]

Disconnect: If we gave you a date for donut would that make you
happier? I doubt it. Or are you suggesting that all the members on
this mailing list should have a democratic vote on the release date,
and us engineers doing the actual work will try really hard to get it
done by that date for you?

Mike

[dan raaka]

Even a extended feature list that could be added in future releases could without specifying which will go to which release. This will give non-googlers (individuals or otherwise) an opportunity to decide if they want to contribute. They could either work with Google, if Google is leading that feature development already.

[Disconnect]

Silence (as now) is one extreme. Those are a couple of others. How about something in the middle? Run AOSP as an open source project, let the closed source trees branch off when they need to based on their secret requirements.

And as the other poster said, even a basic moderately-ordered list of "these are the current engineering priorities" would be a large improvement.

To be very clear, I'm not asking for a date, although it would be nice. I'm asking for tasks. (Or maybe I am missing something - wouldn't be the first time. Iis there a list where the various features/tasks/milestones for each release is being discussed publically? Without that, it sure looks like the same thing all over again.)

[Tim Labeeuw]

Look at how the Eclipse Foundation handles an open source project.
Each component/project has clear and SEPARATE roadmap, wiki,
documentation, bug reports, web pages, mailing lists and so forth.
This allows for a really transparent and encouraging environment for
developers, even occasional/hobbyist developers, to try and
contribute. Furthermore having worked in a corporate environment
contributing to Eclipse this transparency only aided the development.
Big corporations like clearly defined deadlines, release trains and
project structures. The open source community likes transparency. Both
can coexist! Otherwise what is the point of being open sourced!
Before even STARTING development of Donut I would spend a lot of my
resources on building a good ecosystem. Putting the work now, will pay
far larger dividends latter when all the OHA members and enthusiasts
can easily contribute to the AOSP. Specially when OHA members can take
over projects from Google, freeing up the appropriate resources to
develop innovate new projects.

On Apr 23, 3:06 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> Silence (as now) is one extreme. Those are a couple of others. How about
> something in the middle? Run AOSP as an open source project, let the closed
> source trees branch off when they need to based on their secret
> requirements.
>
> And as the other poster said, even a basic moderately-ordered list of "these
> are the current engineering priorities" would be a large improvement.
>
> To be very clear, I'm not asking for a date, although it would be nice. I'm
> asking for tasks. (Or maybe I am missing something - wouldn't be the first
> time. Iis there a list where the various features/tasks/milestones for each
> release is being discussed publically? Without that, it sure looks like the
> same thing all over again.)
>

> On Thu, Apr 23, 2009 at 2:23 PM, Mike Lockwood <lockw...@android.com> wrote:
>
> > Disconnect: If we gave you a date for donut would that make you
> > happier?  I doubt it.  Or are you suggesting that all the members on
> > this mailing list should have a democratic vote on the release date,
> > and us engineers doing the actual work will try really hard to get it
> > done by that date for you?
>
> > Mike
>

> > On Thu, Apr 23, 2009 at 11:09 AM, Disconnect <dc.disconn...@gmail.com>

> > wrote:
> > > So AOSP will continue to be driven by closed source requirements at least
> > > through donut? Thats unencouraging.
>

> > > On Thu, Apr 23, 2009 at 1:49 PM, Dianne Hackborn <hack...@android.com>

> > > wrote:
>
> > >> As always, the current roadmap is here:
>
> > >>http://source.android.com/roadmap
>
> > >> I realize this doesn't provide much detail, but at this point we really
> > >> don't want to be in the position of making even implied commitments that
> > >> people are then going to base device schedules around when we are not
> > >> confident enough about them.
>

> > >> On Wed, Apr 22, 2009 at 11:57 PM, Jerry Jih <jjih0...@gmail.com> wrote:
>
> > >>> Dear Mike,
>
> > >>> 1. How about the release schedule of Donut?
> > >>> 2. How about the major difference between Cupcake and Donut? (WVGA,
> > AGPS,
> > >>> ...)
> > >>> 3. Any impact for CTS and GMS if using Cupcake?
>
> > >>> Jerry
>

> > >>> 2009/4/23 Mike Lockwood <lockw...@android.com>

>
> > >>>> Cupcake is using the 2.6.27 kernel.  We are planning on moving to
> > >>>> 2.6.29 for the next release (donut).
>
> > >>>> Mike
>

> > >>>> On Wed, Apr 22, 2009 at 10:01 AM, Dan Raaka <danra...@gmail.com>

> > wrote:
>
> > >>>> > Please confirm what version of kernel will be in cupcake FC?
>
> > >>>> > The cupcake preview SDK seems to contain 2.6.27, but there are
> > >>>> > references to even 2.6.30 on the gitweb
> > >>>> >http://android.git.kernel.org/?p=kernel/msm.git;a=summary
>
> > >>>> > -Dan
>
> > >>>> --
> > >>>> Mike Lockwood
> > >>>> Google android team
>
> > >> --
> > >> Dianne Hackborn
> > >> Android framework engineer

> > >> hack...@android.com

[Dianne Hackborn]

On Wed, May 6, 2009 at 9:59 AM, Tim Labeeuw <Tim.L...@gmail.com> wrote:

Before even STARTING development of Donut I would spend a lot of my
resources on building a good ecosystem.

It is just not feasible to significantly hold up development (and thus the shipment of devices that manufacturers have schedules to deliver and carriers have in their roadmaps to provide to their customers) for "building a good ecosystem."

As I've said before: this is an on-going process.  I hope that people can see things improving over time.  It's not going to happen all at once, but it is certainly happening.
 

Putting the work now, will pay
far larger dividends latter when all the OHA members and enthusiasts
can easily contribute to the AOSP. Specially when OHA members can take
over projects from Google, freeing up the appropriate resources to
develop innovate new projects.

There is nothing preventing people from contributing, though sure it is not as easy now as would be ideal.  We are in the process of integrating CDMA that was contributed, and are starting to take in other features.  This also takes a lot of time from current developers (such as myself), since for people starting to contribute there is a lot of hand-holding required to get code into acceptable shape so that it accounts for all of the things we need to deal with: well optimized to run efficiently, small size so it will fit on the devices, consistent with the existing code styles, maintainable for binary compatibility in the case of anything that appears in the SDK, etc.  This also is just something that I expect to happen over time, as people learn to work on Android.


To be honest, I care mostly about the people who are actually contributing stuff, much less the people who seem to just complain about how it isn't yet as open as they would like.  (And that is why I try to avoid spending my own time posting on these threads.)

--
Dianne Hackborn
Android framework engineer

hac...@android.com

[Tim Labeeuw]

Thanks Dianne for replying... I fully agree its a difficult and
ongoing process. Particularly the choice of spending resources on
development vs ecosystem building is tough.

BUT I would argue that the carriers and device developers in the short
and defiantly in the long run would reap larger dividends spending the
resources now. Indeed this "good ecosystem" should NOT be built for
the "whiners" or occasional contributors in mind (this should just be
a side effect). A good ecosystem like eclipse is primarily targeted at
the large contributors allowing for less hand holding, more
communication, better bug resolution, better design up front and so
forth. Look at how IBM, Symbian, Windriver etc all develop products on
top of Eclipse without it becoming a mess. As Android is exploding
into new and different devices and markets it threatens to collapse in
on itself if the proper framework/ecosystem is not in place. As you
said yourself your already spending too much time hand holding the
device manufacturers etc now, imagine when there are 20 different
devices on the marketplace. The task to retrofit an ecosystem then
will be far harder and more expensive. Laying a good foundation is
NEVER a bad idea.

Indeed my company (now an enterprise member of Eclipse) would never
have gotten into Eclipse were it not for the great ecosystem, allowing
both the project managers, developers, system analysts, req analysts
etc etc to all understand and move the system forward. Its simple
things like having a mailing list, minutes of meetings, wiki's and
roadmaps for EACH project that really help the individual developer
both at HTC, Sony Ecrisson, Motorola etc and Google to work in tandem
to create a truely unique product.


On May 6, 1:21 pm, Dianne Hackborn <hack...@android.com> wrote:

> hack...@android.com

[Zhihong GUO]

Hi,

Could anybody please tell me where is the implementation source code of SUPL? 

Thanks,

2009/4/24 Mike Lockwood <lock...@android.com>