Re: Last WebKit merge(s) into AOSP

[Jean-Baptiste Queru]

You're looking in the right place, and the same underlying version of WebKit that was merged late into the Ice Cream Sandwich development cycle has been explicitly kept for Jelly Bean (with many additional fixes, of course).

JBQ

On Mon, May 27, 2013 at 3:55 PM, Charly Bowers <stron...@gmail.com> wrote:

Hi!

I was looking at the full merges of WebKit SVN branches into AOSP at the platform/external/webkit repo.
They used to be more or less periodic, and updates to files like WEBKIT_MERGE_REVISION always said something along the lines of "We now track this or that WebKit SVN branch, starting at r123456".
Until about summer 2011, when they apparently stopped?
(I don't mean cherry picks or individual little diffs brought over to AOSP. I know this still goes on occasionally.)

The last one I could find is this one on July 13th of that year:
https://android.googlesource.com/platform/external/webkit/+/d0147a863b872ecaa451ab0dce2a348760e99e2c

"Merge WebKit at branches/chromium/742 r89068: Initial merge by Git."
(By now, WebKit SVN repo has more than 50% more commits than at that time, so I feel I am constantly overlooking something.)


Only a month later (August 2011), this was posted:
https://lists.webkit.org/pipermail/webkit-dev/2011-August/017738.html

However, I may be too dumb to see a connection if there is one.

The Chromium repo regularly updates its WebKit revision all the time.
But Android's current WebKit code still lives at googlesource.com, right? I could not find any hint in the AOSP repos or mailing lists that says otherwise.

If the given merge in 2011 is truly the last one, why so?

If not, could you please point to me to the last full merge or what to look for in the repo(s) or elsewhere to figure this stuff out?

Thanks!

Regards,
Charles

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jean-Baptiste M. "JBQ" Queru
Technical Lead, Android Open Source Project, Google.

Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.

[Charly Bowers]

Thank you, Jean-Baptiste!
A swift response from the man himself, much appreciated.

It might not matter to most devs, but out of scientific curiosity, if we can be told:
what led to that decision to lay off the practice of the periodic merges after that last merge, though?

Doesn't that also lead to a lot more cherry-picking commits from upstream to fix bugs, since newer bugfixes aren't in part already covered by those merges anymore?
So, is the "maintenance overhead" (time spent on) of the assumed increase in cherry picks smaller than the maintenance overhead incurred by merging upstream branches? Was that the reason to stop those merges?

(I hope it's OK to dig into such questions/areas in this forum.)

Regards,
Charles

[Jean-Baptiste Queru]

I don't think that I have enough knowledge or authority to get into details, given that I'm also watching from the sidelines, so I'll have to limit myself to vague high-level statements of doubtful accuracy.

As Andrei suggested in the email you linked, one big difficulty with merges has been that Android-specific code didn't get tested in upstream WebKit (I'm not assigning blame here, just stating a fact). As a result, full merges were disruptive, because nobody could predict how they would turn out, and because each merge would be followed by a period of bug-fixing. Targeting cherry-picking doesn't have such problems.

At the same time, with Chrome being ported to Android, there were suddenly two variants of WebKit that target Android (Chrome's and Android's), between which the link was upstream WebKit where Android wasn't as directly in focus (again, I'm not assigning blame here, just stating a fact). Resolving that problem has been slowing things down: process improvements that target long-term gains usually involve short-term costs.

JBQ

[Michael Moussa]

It looks to be going done the same path as a lot of other bundled AOSP system apps. Apps which Google seems to have an equivalent that they ship alongside with CTS certified Android devices are not getting much development effort in AOSP. For Example the music player app in AOSP has not got much updates since Google Play Music came out. I am not saying what Google is doing is wrong, in fact I agree with the path they are taking from a business perspective. If they give everything away in AOSP, why would a manufacturer play along with Google and get certified (think Amazon kindle fire, Barnes and Nobles Nook).

However with that said the browser is a bit of a different animal as webviews use the system browser, not chrome, so you cannot really equate it to the music player app. 

Mike

[Jean-Baptiste Queru]

WebView is a public API and it's most definitely not going away.

JBQ

[Michael Moussa]

This may better explain it:

https://www.youtube.com/watch?feature=player_embedded&v=GPjlubm32DM#t=260s
at time 4:30

[Charly Bowers]

Thanks, nice catch!

[Charly Bowers]

Thank you for taking the time to write out your thoughts on this.

He himself wrote about "the incomplete Android port that exists today in WebKit" in the email, so I take it that the assumptions you state here could be grounded in that the Android-specific parts were never really fully upstreamed before that email.

Now, after thinking about it a little more, what I don't get is this:

Several articles on the net picked up on said email and some mentioned the implication that Google now (i.e., after the events surrounding the email) only has one WebKit port to maintain.
I guess they meant the Chromium port instead of Chromium + Android ports.
But then, if that was indeed true, why can't Android just point to specific WebKit SVN revisions in a (periodically updated) DEPS file placed somwhere in AOSP just like Chromium does in its own repo since now so much code surrounding several things (like WebKit, network stack, etc.) is being shared betwenn Android and Chromium (see email)?
Doesn't the continued cherry-picking activity in Android AOSP WebKit mean double maintainance like before? How is there a change in how many ports of WebKit Google needs to maintain? If there were only one port to maintain, why is that not happening only in the Chromium repo, or am I misunderstanding the meaning and intention of the advantages mentioned in the email and in the blog chatter that followed?

Regards,
Charles

[Michael Moussa]

So Google forked WebKit into Blink. Chromium/Chrome now uses Blink and based on the fireside chat with the chrome team it sounds like the Android internal browser as well as the webview will move to using blink/chromium instead of webkit in the future. I am not sure if this reduces the amount of ports that Google needs to maintain, but I think this may be easier for them to support since they are already supporting Chrome on Android, supporting chromium on Android won't be too much different.

[Charly Bowers]

Hi Michael.
Thanks for your input.

To me, Blink's the stuff from the future.
In my post above I am still trying to figure out 2011. ;-)

[Jean-Baptiste Queru]

To quote the Chrome fireside chat that was linked earlier in the thread, "that's something that's being worked on".

The key here is that when something is conceptually simple but technically hard (i.e. "Use WebKit from Chrome into Android's WebView"), it's really hard to grasp the proper timeframes. It's only been 2 years, and given the magnitude of the work that's not unreasonable.

Back in 2011, the Chrome team was working on Chrome as a standalone browser, based on r18. That's what you saw in early 2012. They then closed the gap with the desktop versions, caught up at r25, and are now keeping up.

Merging that work into WebView is being worked on, like the Chrome team said, and the cherry-picking activity you've been seeing in the existing WebView is only a temporary surface solution while the deep stuff is happening.

From where I'm sitting that's really about all I see.

JBQ

[Charly Bowers]

Oh man, thanks, you cleared it up for me!

As people across the web got so hyped up about that email, I took the email's and blogs' mentionings way too matter-of-factly instead of as simply something "visionary" (a vision of a new plan or approach), causing me to think "Google having to maintain only one port of WebKit" was already happening as of that email or shortly thereafter, at least within that year of 2011, thus leading to me seeing contradictions.

Now I understand why we should also mention Blink, I think.

Doesn't the plan of creating Blink (forking WebKit for use in Chrome/Chromium) make the vision in that email go totally down the drain?

Regards,
Charles

[Charly Bowers]

As far as I now understand, that amount should stay the same.
Instead of maintaining Android's WebKit and Chromium's WebKit, they we will maintain Android's WebKit and Chromium's Blink.

Regards,
Charles

On Wednesday, June 5, 2013 2:39:10 AM UTC+2, Michael Moussa wrote:

[Jean-Baptiste Queru]

As I understand, the plan is still for Android to follow Chromium's lead in terms of HTML/CSS/JS. As Chromium moves to Blink, so should Android, eventually. I have no idea how far in the future we need to look.

JBQ

[Charly Bowers]

By the time *that* would ever be completed, I'll guess the long-term plan would be that they will just kick the stock browser and do everything at chromium.org - one Chromium browser for Android that everyone can fully build completely from open-source material, while Chrome remaining as the flagship model.
Now I'm just speculating myself. ;-)
Thanks for your help and comments you gave in this thread.

[Michael Moussa]

Charly, that is what I was speculating as well. I am just less skeptical than you on the timing.