Moving //third_party/WebKit to //web

[TAMURA, Kent]

We're planning to move //third_party/WebKit to //web. We don't have estimated date to execute the plan yet, and we'll send another notification when we decide the date.

 

We'll apply lower_case file and directory names during the move. We might move the top-level directories (Source/, LayoutTests/, PerformanceTests/, Tools/, etc.) separately.

 

More information: The Great Blink mv

Tracking bug: crbug.com/622551

--

TAMURA Kent
Software Engineer, Google

[Yutaka Hirano]

Will we have a tool to migrate local branches? I had a bad rebase experience on Blink renaming, and don't want to experience it again.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Nico Weber]

On Sun, Apr 16, 2017 at 9:30 PM, 'Yutaka Hirano' via blink-dev <blin...@chromium.org> wrote:

Will we have a tool to migrate local branches? I had a bad rebase experience on Blink renaming, and don't want to experience it again.

Slight thread hijack: If you have problems like this, please make them known somewhere else than an offhand remark on an unrelated thread. To me, the developer feedback to the rebasing after the reformatting (which was 100% transparent and didn't require any work) and the renaming (which was pretty manual) was up to now identical (and I only happened to see this unrelated thread here by accident). So my lesson so far was that devs don't care too much about rebase helpers.

[Daniel Cheng]

yutak@, it's too late for your particular issue now, but if you still remember what CLs had issues, any pointers to the problematic CLs would be greatly appreciated. We do have a known issue with the tool where it doesn't handle newly added files (https://crbug.com711127), so I'm not sure if that's the bug you encountered, or something else. Thanks.

Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Yutaka Hirano]

I'm yhirano@.

I didn't use the rebase helper. I started rebasing before it was released.

Looking at the mail thread, I've just noticed I overlooked an prior notice. So it was my fault, sorry!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Kentaro Hara]

+beng +dglazkov

--

Kentaro Hara, Tokyo, Japan

[TAMURA, Kent]

I thought git just worked well in many cases because the move won't change the source content except #includes. However probably we need a rebase tool anyway to help file removal/addition in CLs.

[Jochen Eisinger]

Note that +Dirk Pranke recently started to move WebKit/Tools stuff to //blink

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[TAMURA, Kent]

We haven't started any work depending on the destination directory or the directory structure in the destination.  Feedback is welcome.

On Mon, Apr 17, 2017 at 9:23 AM, TAMURA, Kent <tk...@chromium.org> wrote:

[Raymond Toy]

In that case, can we use //blink instead of //web?

//web is, um, so boring.  //blink is cool.

I'm a BlinkWorker not a WebWorker.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Anton Vayvod]

According to the doc there was a discussion about the name already: https://groups.google.com/a/chromium.org/forum/#!topic/platform-architecture-dev/DKQn-SILZzo

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Raymond Toy]

Dang.  Oh well, Onward and upward.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Dimitri Glazkov]

FWIW, naming is hard and I am trying to write my thoughts down and share with y'all, please stay tuned.

:DG<

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Anton Vayvod]

Sorry if my reply was discouraging, I only meant to highlight the context existence here.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Łukasz Anforowicz]

On Monday, April 17, 2017 at 10:15:02 PM UTC-7, Kent Tamura wrote:

I thought git just worked well in many cases because the move won't change the source content except #includes. However probably we need a rebase tool anyway to help file removal/addition in CLs.

It seems that git works fine, but gitiles doesn't - see https://crbug.com/701516.

[Dirk Pranke]

Actually, I was only adding owners, team, and component information to the previously existing directories; I wasn't planning to move anything to //blink.

-- Dirk

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Dimitri Glazkov]

As promised, here's an essay on Blink :)

https://docs.google.com/document/d/18qpNBY3Xm2svzBSAgOJk_Kkb_iRJXCsZQO4Oa3wv3n4/edit?usp=sharing

I tried to read over all of the comments from the great blink mv threads/docs, recall the history, look at the future, and then to write it all down. I would love y'all's reflections and insights. Let me know if I missed things, and I'll incorporate them into the doc.

:DG<

[Jeremy Roman]

Thank you for writing this; I think it captures a number of important points. My two cents (as someone in camp 2, but who does think //blink makes at least some sense):

The code

Blink is the Chromium project's implementation of the web platform (and in particular, HTML and related specs). I see the difference between "rendering engine" and "web platform implementation" (i.e., "application runtime environment") as more a sign of the evolution of how the Web is seen (from hosting documents to applications).

I'd say that "Blink is the code", but that doesn't mean it's all of the code; most libraries are not entirely self-contained. One can define "HTML implementation" to mean anything from "the HTML parser" to "Chrome web browser" (or if you want to really stretch it, "the Chromebook sitting on my desk"), and I don't think it's surprising that we have to select how to divide it into pieces that are easy to build and talk about. Some pieces of our web platform implementation are currently separate from Blink, such as the network stack, and others are even separate from the src repository, such as V8.

(Namespaces and crbug components would ideally mirror the code, IMHO.)

The community

Some parts of the "Blink community/process" (for example, the "Intent-to-Ship" process) would ideally be framed as a somewhat outward-facing "Chromium web platform community/process", because changes to our JavaScript language support, HTTP/TLS/DNS behaviour, and so on affect web developers similarly to changes in our HTML and CSS implementations. Indeed the intent process seems to be being used increasingly for such changes. Similarly, I think the decision-maker title would ideally be "Chromium web platform API owner", rather than "Blink API owner", as the decisions they make are about our interface with web developers, regardless of the implementation details (though in practice those people have a dual role as code owners).

The other part of the "Blink community" is the more inward-facing "group of people who work on this particular set of source files", which includes discussions like "why doesn't my IDL file build" and "what changes are happening to WTF".

These groups have a large overlap (because Blink-the-codebase's purpose is to do the things the Chromium web platform community decide it should do), which is why we share gathering places (like blink-dev, BlinkOn, etc.). Having separate mailing lists is a thing we could do if it made sense, but I don't want to go to twice as many conferences per year. :)

The project/product

In my mind, neither of these is Blink. The project is Chromium, and the product is the web browser (Chrome, Opera, etc.).

[Dimitri Glazkov]

On Tue, Apr 25, 2017 at 9:32 PM Jeremy Roman <jbr...@chromium.org> wrote:

Thank you for writing this; I think it captures a number of important points. My two cents (as someone in camp 2, but who does think //blink makes at least some sense):

The code

Blink is the Chromium project's implementation of the web platform (and in particular, HTML and related specs). I see the difference between "rendering engine" and "web platform implementation" (i.e., "application runtime environment") as more a sign of the evolution of how the Web is seen (from hosting documents to applications).

That's really useful insight. Our evolving understanding of our product does seem to be influenced by how it is perceived by our users (the web developers, in this case). Incorporated into the doc.

 

I'd say that "Blink is the code", but that doesn't mean it's all of the code; most libraries are not entirely self-contained. One can define "HTML implementation" to mean anything from "the HTML parser" to "Chrome web browser" (or if you want to really stretch it, "the Chromebook sitting on my desk"), and I don't think it's surprising that we have to select how to divide it into pieces that are easy to build and talk about. Some pieces of our web platform implementation are currently separate from Blink, such as the network stack, and others are even separate from the src repository, such as V8.

(Namespaces and crbug components would ideally mirror the code, IMHO.)

Agreed!

 

The community

Some parts of the "Blink community/process" (for example, the "Intent-to-Ship" process) would ideally be framed as a somewhat outward-facing "Chromium web platform community/process", because changes to our JavaScript language support, HTTP/TLS/DNS behaviour, and so on affect web developers similarly to changes in our HTML and CSS implementations. Indeed the intent process seems to be being used increasingly for such changes. Similarly, I think the decision-maker title would ideally be "Chromium web platform API owner", rather than "Blink API owner", as the decisions they make are about our interface with web developers, regardless of the implementation details (though in practice those people have a dual role as code owners).

Agreed. I also see this gap between "Blink as the rendering engine" and "Blink intent process is the Chromium web platform process".

 

The other part of the "Blink community" is the more inward-facing "group of people who work on this particular set of source files", which includes discussions like "why doesn't my IDL file build" and "what changes are happening to WTF".

That's good insight. Incorporated into the doc.

 

These groups have a large overlap (because Blink-the-codebase's purpose is to do the things the Chromium web platform community decide it should do), which is why we share gathering places (like blink-dev, BlinkOn, etc.). Having separate mailing lists is a thing we could do if it made sense, but I don't want to go to twice as many conferences per year. :)

Yeah, it's tricky. In a sense, I would be okay with having the same community host both groups: since they are largely overlapping, there might be an advantage to treating them as part of the same thing.

[lambros...@chromium.org]

Hi,

This proposed Blink move was brought to my attention on this chromium-dev thread.

I'm looking into how we generate the about:credits page (and related credits lists) in Chrome, and was wondering if there's a plan for dealing with third-party-licensed (not Chromium) code in Blink (assuming such code still exists)?

The current policy for Chrome says:

We put all code that isn't written by Chromium developers into src/third_party (even if you end up modifying just a few functions). We do this to make it easy to track license compliance, security patches, and supply the right credit and attributions. It also makes it a lot easier for other projects that embed our code to track what is Chromium licensed and what is covered by other licenses.

(It goes on to allow third_party subdirectories as well.)

It would be really nice to have separate third_party directories within Blink for all non-Chromium-copyrighted files, but I guess this isn't feasible? In which case, we might have to treat the whole of Blink as a single third-party entity, with an aggregated license and a single entry in about:credits (as we currently do today)?

In any case, I just wanted to raise awareness of Chrome's policy regarding third-party code, and ensure we have a plan for addressing it. This may mean tweaking Chrome policy to treat Blink as a special case, and tweaking the Credits code in tools/licenses.py.

Many thanks!

[Dimitri Glazkov]

To close the loop and unblock this thing. There are tons of opinions, all of them are have valid points and it's hard to tell which one is really the right one. I spoke with a bunch of y'all over the last few weeks and I synthesized the following:

<decider-hat-on>

* As I stated, in Blink is Chromium project's implementation of the Web Platform.

* The new destination for //third_party/WebKit is //blink/renderer.

* We will eventually also have //blink/browser or //blink/host, and move all Web Platform related bits there.

</decider-hat-off>

Kent-san:

* Adjust your proposal accordingly. Please let me know if you need help with specifics.

* make sure to work out the timeframes with Kentaro and other relevant folks. They have several related projects in flight that may be affected.

* get this proposal ratified by src/ENG_REVIEW_OWNERS. I'll help champion it.

:DG<

[Daniel Cheng]

On Fri, May 26, 2017 at 10:00 AM Dimitri Glazkov <dgla...@chromium.org> wrote:

To close the loop and unblock this thing. There are tons of opinions, all of them are have valid points and it's hard to tell which one is really the right one. I spoke with a bunch of y'all over the last few weeks and I synthesized the following:

<decider-hat-on>

* As I stated, in Blink is Chromium project's implementation of the Web Platform.

* The new destination for //third_party/WebKit is //blink/renderer.

* We will eventually also have //blink/browser or //blink/host, and move all Web Platform related bits there.

Currently, renderer is split between //chrome and //content. Will we still have a place for Chrome-specific renderer code?

Daniel

 

</decider-hat-off>

Kent-san:

* Adjust your proposal accordingly. Please let me know if you need help with specifics.

* make sure to work out the timeframes with Kentaro and other relevant folks. They have several related projects in flight that may be affected.

* get this proposal ratified by src/ENG_REVIEW_OWNERS. I'll help champion it.

:DG<

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx5aWsPHLNnGPvr0GmUi8rB1VmNv6_jgre_rDpd7yFM6Pg%40mail.gmail.com.

[Dimitri Glazkov]

On Fri, May 26, 2017 at 10:23 AM Daniel Cheng <dch...@chromium.org> wrote:

On Fri, May 26, 2017 at 10:00 AM Dimitri Glazkov <dgla...@chromium.org> wrote:

To close the loop and unblock this thing. There are tons of opinions, all of them are have valid points and it's hard to tell which one is really the right one. I spoke with a bunch of y'all over the last few weeks and I synthesized the following:

<decider-hat-on>

* As I stated, in Blink is Chromium project's implementation of the Web Platform.

* The new destination for //third_party/WebKit is //blink/renderer.

* We will eventually also have //blink/browser or //blink/host, and move all Web Platform related bits there.

Currently, renderer is split between //chrome and //content. Will we still have a place for Chrome-specific renderer code?

Yes. The line between Web Platform bits (that is, things that affect interoperability of the Web Platform) has not been clear at this point, and I would like for us to be more explicit about this. If the Chrome-specific renderer code is part of Web Platform, it goes into //blink somewhere.

:DG< 

[Fernando Serboncini]

On Fri, May 26, 2017 at 1:00 PM Dimitri Glazkov <dgla...@chromium.org> wrote:

* The new destination for //third_party/WebKit is //blink/renderer.

Could you clarify this a bit? will this be //blink/renderer/Source/core/...

Could I suggest that /Source becomes /renderer and other top level directories directories go under //blink?

or was this already inside the decider hat scope?

[]s

F.

[Dimitri Glazkov]

On Fri, May 26, 2017 at 10:59 AM Fernando Serboncini <fs...@google.com> wrote:

On Fri, May 26, 2017 at 1:00 PM Dimitri Glazkov <dgla...@chromium.org> wrote:

* The new destination for //third_party/WebKit is //blink/renderer.

Could you clarify this a bit? will this be //blink/renderer/Source/core/...

Please see the original doc for the details in Kent-san's proposal:

https://docs.google.com/document/d/1l3aPv1Wx__SpRkdOhvJz8ciEGigNT3wFKv78XiuW0Tw/edit#heading=h.xgjl2srtytjt

 

Could I suggest that /Source becomes /renderer and other top level directories directories go under //blink?

I believe that's part of his proposal.

 

or was this already inside the decider hat scope?

Nope. I tried to keep that hat scope as small as possible to give Kent-san room to work.

:DG<

[Kentaro Hara]

Regarding the timeline, I don't have any strong opinion. However, I'd note that Onion Soup 2.0 will massively clean up the renderer architecture, removing renderer code from //content/, //chrome/, all public APIs and Web types. Onion Soup 2.0 will clarify what the renderer process is, so it might be easier to restructure the directories after finishing Onion Soup 2.0 (although you don't need to block the directory move on Onion Soup 2.0).

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx4LZ96EtGD4m0FHR9ioytyUu_x43AXV2wJj_vuT%2B2B60A%40mail.gmail.com.

[TAMURA, Kent]

Dimitri, thank you for the coordination.

I'll propose //blink to ENG_REVIEW_OWNERS if we won't have objections in a few days.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx5aWsPHLNnGPvr0GmUi8rB1VmNv6_jgre_rDpd7yFM6Pg%40mail.gmail.com.