(Names removed as don't think they're important to repost. And not intending this as incendiary. At some point someone needs to ask "How much are we impacting usability by stripping features?")
"1 week ago (2015-06-09 02:17:42 UTC) #19
On 2015/06/09 01:34:04, _ wrote:
> On 2015/06/09 01:13:10, _ wrote:
> > Done, but I'm going to voice my opposition to this. When I took over the
> > hotwording code, there were a number of obscure hoops to jump though to get
> this
> > to work locally. They've been eliminated. Having to find these pair of
> #defines
> > and changing them is more obscure to a newcomer than a build flag (that can
> > easily be traced through the code).
>
> What about having a run time flag for enabling hotwording? We would always
> enable hotwording for Google Chrome builds, and check for it in Chromium
builds.
> That way, Chromium users can make the decision to use the feature, rather than
> the Chromium distributor. And it won't require hotwording developers to build
> with GOOGLE_CHROME_BUILD or do any #ifdef hacking.
We shouldn't be exposing feature-enables to end users as runtime switches.
Honestly, I think the right thing to do is for Chromium users to get this by default but have a build switch that can be used to disable it for projects like Debian that feel more strongly about not having any external binary blobs used for anything. I don't think simply disabling this in general for Chromium is correct. It's not true that Chromium by definition should not make use of such blobs, and I think the damage to developers and to more pragmatic users of Chromium-based projects is greater than we should be willing to pay."
https://codereview.chromium.org/1160243004
(Names removed as don't think they're important to repost. And not intending this as incendiary. At some point someone needs to ask "How much are we impacting usability by stripping features?")
"1 week ago (2015-06-09 02:17:42 UTC) #19
On 2015/06/09 01:34:04, _ wrote: > On 2015/06/09 01:13:10, _ wrote: > > Done, but I'm going to voice my opposition to this. When I took over the > > hotwording code, there were a number of obscure hoops to jump though to get > this > > to work locally. They've been eliminated. Having to find these pair of > #defines > > and changing them is more obscure to a newcomer than a build flag (that can > > easily be traced through the code). >
> What about having a run time flag for enabling hotwording? We would always > enable hotwording for Google Chrome builds, and check for it in Chromium builds. > That way, Chromium users can make the decision to use the feature, rather than > the Chromium distributor. And it won't require hotwording developers to build > with GOOGLE_CHROME_BUILD or do any #ifdef hacking.
We shouldn't be exposing feature-enables to end users as runtime switches.
Honestly, I think the right thing to do is for Chromium users to get this by default but have a build switch that can be used to disable it for projects like Debian that feel more strongly about not having any external binary blobs used for anything. I don't think simply disabling this in general for Chromium is correct. It's not true that Chromium by definition should not make use of such blobs, and I think the damage to developers and to more pragmatic users of Chromium-based projects is greater than we should be willing to pay."