Hi,
There is a difference between a library and an end-user application. Having "updaters" for end-user applications seems to be the status quo on Windows and to a lesser extent on Macs, but is resented on Linux. Having a library do these checks is not okay anywhere.I remember a session at the Google Summer of Code where some guy from one of the open source wikis shared his experiences with having embedded a 'counter pixel' in a release. In short, his lesson learned was that any kind of "phoning home" is an absolute no-go unless made *very* clear to the users (plus opt-out). This was pre-Snowden, so many people are now much more sensible with respect to these matters... I am all for a configure opt-out, and noting it in every piece of documentation. My impression of the level of sophistication of most users is that we will see few opt-outs.
I bet that some Germans would still be very upset about an opt-out rather than an opt-in (yes, this is a cultural issue...).
Is there much value from a nagupgrade check at configure-time? Those who download a fresh copy of PETSc don't have any benefit from the check. After the installation, the check has no effect (Matt, I remember your fieldsplit slides where you say that students only install at the beginning of your PhD, then work entirely with options). For those who configure frequently, a regular update is part of the work flow anyway. So, who really benefits from nagupgrade?
Best regards, Karli
