I certainly see the value of telemetry in being able to produce a higher quality product through understanding user behavior. However, I am not sure it is realistic. My clients are very conscious of intellectual property and data privacy concerns, and for some of them, even discussing the possibility of allowing telemetry in any part of the technology stack would damage their trust in me. Even if there were an easy opt-out feature, I would be very concerned that I or someone on my team would accidentally build client code without opting out, and I would have to take serious steps to ensure that this could never occur.
I would be thrilled, of course, if such analyses could be easily performed against publicly available code on Hackage, as many tests have done in the past. This would also provide an additional small incentive for people to open source code that they do not have a strategic need to keep secret. MarLinn's idea sounds like a good approach to me, although I agree that it has difficulties. I think the key would be to make the report produced brief, human-readable, and clear enough that a CTO or other executive could easily sign off on "declassifying" it. We could then ask that companies voluntarily submit this report if they wish to have an impact on prioritizing the future of the language. I suppose this is a very strict version of "opt-in", and generally I think that opt-in would be fine, as long as we're very confident that we'll never have a bug that makes it opt-out instead. Ryan On Fri, Dec 9, 2016 at 12:13 PM, MarLinn via ghc-devs <ghc-devs@haskell.org> wrote: > Pretty random idea: What if ghc exposed measurement points for performance > and telemetry, but a separate tool would handle the read-out, > configuration, upload etc. That would keep the telemetry from being > built-in, while still being a way to get *some* information. > > Such a support tool might be interesting for other projects, too, or even > for slightly different use cases like monitoring servers. The question is > if such a tool would bring enough benefit to enough projects for buy-in and > to attract contributors. And just separating it doesn't solve the > underlying issues of course, so attracting contributors and buy-in might be > even harder than it already is for "normal" projects. Close ties to ghc > might improve that, but I doubt how big such an effect would be. > > Additionally, this approach would just shift many of the questions over to > Haskell-platform and/or Stack instead of addressing them – or even further, > on that volatile front-line space where inner-community conflict roared > recently. It wouldn't be the worst place to address them, but I would > hesitate to throw yet another potential point of contention onto that > burned field. > > Basically: I like that idea, but I might just have proven it fruitless > anyway. > > > Cheers, > MarLinn > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
