openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "seba.wagner@gmail.com" <seba.wag...@gmail.com>
Subject Re: Error collecting infrastructure for Openmeetings
Date Tue, 11 Jun 2013 23:16:53 GMT
*AFAIK,
many Apache projects do use Google Analytics already.*
=> The next question will be: Which projects do you Google Analytics?

I doubt that any Apache product includes a UA code in its release packages.

Sebastian


2013/6/10 Alexei Fedotov <alexei.fedotov@gmail.com>

> [added general@ for vivid discussion]
>
> Hello Sebastian,
>
> I'm glad that the statement that this infrastructure is needed is not
> questioned.
>
> We technically can use either CGI script, or existing Confluence API.
> The intention for using Google Analytics is minimum effort. AFAIK,
> many Apache projects do use Google Analytics already.
>
> The goal for the request is to avoid inventing a project-wide policy
> where foundation-wide policy is needed.
>
> With best regards, Alexei
>
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> http://dataved.ru/
> +7 916 562 8095
>
>
> On Mon, Jun 10, 2013 at 7:03 AM, seba.wagner@gmail.com
> <seba.wagner@gmail.com> wrote:
> > Hi Alexei,
> >
> > what about a simple CGI script that takes the input and send an email to
> the
> > mailing list?
> > I think some more simple approach would do the same and does not have
> such a
> > deep impact on the whole infrastructure. Some legal and privacy aspects
> are
> > still tbc.
> >
> > However no matter what we do it is unlikely that including the actual UA
> > code or any kind of real pwd / hash in a release is a good idea. It is
> quite
> > easy to manipulate that.
> >
> > Also the question rises if the OpenMeetings server is in a public
> network at
> > all. Just sending request blindly without knowing if they ever reach
> their
> > destination is kind of odd.
> >
> > It should be some subscribe mechanism where an OpenMeetings admin can
> > activate the error collecting. The activation could then subscribe and
> load
> > a hash that will auth that server for error collecting.
> >
> > If you put that activation in the installer with appropriate
> explenations I
> > think it has better chances to find a wider positive reaction in devs and
> > users.
> >
> > Maybe it would be enough to give some kind of more general feedback from
> > @legal and @infra and we can then in the OpenMeetings PMC create a more
> > detailed spec of that component.
> >
> > @legal: Do you have general constraints regarding error collecting ?
> >
> > @infra: What kind of advices can you give us? I guess some CGI scripts
> are
> > not that big deal. Is there any process who would review and activate /
> make
> > them executable?
> >
> > Thanks,
> > Sebastian
> >
> > Am 06.06.2013 19:38 schrieb "Alexei Fedotov" <alexei.fedotov@gmail.com>:
> >
> >> [added Shane for reputation issues]
> >>
> >> Hello, Infra and Legal folks,
> >>
> >> We ask you for advice on the automated error collection
> >> infrastructure. Any helpful ideas are appreciated.
> >>
> >> 1. Our users are tainted with iphones and other reliable and fancy
> >> staff. They start wanting openmeetings to work reliably. This makes us
> >> think of a global error collecting infrastructure to plan important
> >> bug fixes. Here is an example by Firefox [1].
> >>
> >> We believe collecting user errors is generally ok if proper
> >> preparations are made. Is it generally possible to implement error
> >> collecting infrastructure as a part of Apache project? If not, we can
> >> try to do it as a commercial company, yet Firefox example shows a
> >> non-commercial org can be behind that error collection.
> >>
> >> 2. Could we use Google Analytics to store collected errors? The
> >> general Apache practice is to use Apache infrastructure. Google
> >> Analytics allows us storing 50 mln. events for free. The comparable
> >> thing won't be free for Apache for sure.
> >>
> >> Once can use JIRA, or Confluence via API, this will be a heavy load.
> >> Are you ok with using third party for storing error & environment
> >> messages and associated risks?
> >>
> >> The code we are talking about is below:
> >>        try {
> >>                _gaq = _gaq || [];
> >>                _gaq.push(['_setAccount', 'UA-13024987-1']); // PMC id
> >>                _gaq.push(['_trackPageview']);
> >>                _gaq.push(['_trackEvent', 'Openmeetings client error',
> >> message, '', 0, true]);
> >>        } catch (exception) {
> >>                alert(exception);
> >>        }
> >>
> >> 3. Is it ok for PMC to share Google Analytics id? Should we use some
> >> Apache Id instead?
> >>
> >> 4. Which preparations should be done to start this error collection
> >> service in the next release?
> >>
> >> 4.1. Is it ok just to semi-silently mention in release notes, that
> >> errors are automatically sent to the (Google) server right now?
> >> 4.2. Or should we explicitly notify each new user that the errors are
> >> now to be collected?
> >> 4.3. If 4.2. holds, can we ask once per user at the beginning of his
> >> session and remember if he agreed sharing error reports? Or should we
> >> allow a user to review each error report each time the error is sent
> >> (I expect 5-10 errors per standard openmeetings session)? Can we have
> >> a checkbox "Remember my choice" or a button "Send error reports
> >> always" for those, who are tied of error messages?
> >>
> >> [1]
> >>
> https://crash-stats.mozilla.com/report/index/050f1aab-1507-4c8f-a166-9b3322130422
> >>
> >> --
> >> With best regards / с наилучшими пожеланиями,
> >> Alexei Fedotov / Алексей Федотов,
> >> http://dataved.ru/
> >> +7 916 562 8095
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message