Issue metadata
Sign in to add a comment
|
[Component Request] Blink>Internals>Frames |
||||||||||||||||||||||
Issue description1] Component Name: Blink>Frames Guideline 1 (Clarity): Component name should be descriptive beyond the core project team (i.e. please avoid using non-industry standard abbreviations, code words, project names, etc...) Guideline 2 (Permanence): Component names should describe features/ functions and not team names, code locations, etc..., which are more subject to change and make the hierarchy less predictable for people triaging issues. Guideline 3 (Specific): Components are meant to explicitly track functional work areas. If you are trying to track a Proj(ect) or an on-going effort (e.g. Hotlist-Conops), please instead request a label for a (Proj- or Hotlist-) Guideline 4 (Discoverable/ Predictable): Components should be parented where people would logically expect to find them (i.e. follow product decomposition when naming versus team decomposition) 2] Parent Component (e.g. Blink, UI>Browser, etc...): Blink Note: We generally avoid creating new component namespaces, unless there is a new hierarchy that needs to be expressed. Please try and use existing components as parents. 3] Description of Component: Work on cleaning up and simplifying the existing frame infrastructure and developing the embedding framework. 4] Admin/ Owner: slangley@chromium.org 5] Please specify what triage practices will be followed for the component (i.e. what team will do it and how frequently). I will triage weekly along with sashab@, joelhockey@, loyso@ and nverne@ as partiipating team members.
,
Feb 23 2017
Two types of bugs will be added to Blink>Frames. 1) Internal refactorings/cleanup/improvements to the frames architecture. 2) External issues related to the "embedding framework" project.
,
Feb 24 2017
> 1) Internal refactorings/cleanup/improvements to the frames architecture. IMO, Blink>Internals can cover such stuff. We can add Blink>Internals>Frames, or we can use Blink>Internals and Hotlist-Frames(?). > 2) External issues related to the "embedding framework" project. Is is web-exposed behavior? Does it have a public specification?
,
Feb 24 2017
Is there guidance on what components should be under Blink> and what components should be elsewhere? "embeddeding framework" would not be web exposed, it would be used by embedders of the web platform. (i.e. people putting blink inside some other product). esprehn@ suggested "Blink>Frames" - i personally don't feel strongly one way or the other but would like to understand the criteria by which these things are decided.
,
Feb 24 2017
Basically subcomponents of Blink are web-exposed APIs/behaviors with some exceptions such as Blink>Infra and Blink>Internals though this is not stipulated. Adding more exceptions aren't welcome, and I recommend to add new subcomponent to Blink>Internals or use Blink>Internals and Hotlist- or Proj- labels.
,
Feb 28 2017
Let's just go for Blink > Internals > Frames then. Thanks
,
Feb 28 2017
,
Feb 28 2017
Created Blink>Internals>Frames and added slangley@chromium.org, please feel free to edit the component settings at the link below. https://bugs.chromium.org/p/chromium/components/detail?component=Blink%3EInternals%3EFrames |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by tkent@chromium.org
, Feb 23 2017