[Phpmyadmin-devel] Error reports

[Mohamed Ashraf]

On Tue, Jul 9, 2013 at 10:53 AM, Dieter Adriaenssens
<dieter.adriaenssens at gmail.com> wrote:
> 2013/7/8 Mohamed Ashraf <mohamed.ashraf.213 at gmail.com>:
>> On Mon, Jul 8, 2013 at 5:56 PM, Dieter Adriaenssens
>> <dieter.adriaenssens at gmail.com> wrote:
>>> 2013/7/8 Mohamed Ashraf <mohamed.ashraf.213 at gmail.com>:
>>>> On Mon, Jul 8, 2013 at 4:33 PM, Dieter Adriaenssens
>>>> <dieter.adriaenssens at gmail.com> wrote:
>>>>> 2013/7/7 Mohamed Ashraf <mohamed.ashraf.213 at gmail.com>:
>>>>>> On Sun, Jul 7, 2013 at 12:34 PM, Dieter Adriaenssens
>>>>>> <dieter.adriaenssens at gmail.com> wrote:
>>>>>>> 2013/7/5 Mohamed Ashraf <mohamed.ashraf.213 at gmail.com>:
>>>>>>>> For the server side component of the error reporting system. What are
>>>>>>>> the things you want to do with the reports. like for example comments,
>>>>>>>> or storing status of the reports. what other things do think you would
>>>>>>>> want to do on the error reporting server.
>>>>>>>>
>>>>>>>> What I am thinking is commenting, changing status, searching and of
>>>>>>>> course viewing all the details of the report as well as related
>>>>>>>> reports.
>>>>>>>>
>>>>>>>> Do you want the ability to delete error reports or just mark them as
>>>>>>>> resolved. and while we are on the matter what are the statuses that
>>>>>>>> should exist for the error reports. I am thinking at least new and
>>>>>>>> resolved but I cant think of anything else;
>>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I see this server as a go-between for getting error reports into our
>>>>>>> existing bug-tracker [0] at Sourceforge.
>>>>>>>
>>>>>>> I think it should gather error reports, group them and have the
>>>>>>> possibility of inserting it in the bug-tracker, no need to mimic the
>>>>>>> functionality of the existing bug-tracker.
>>>>>> I was going to do something like that for github issues since I am
>>>>>> already using github authentication. I think that doing this for
>>>>>> sourceforge issue tracker is better since it the one you actually use.
>>>>>> I however cannot use sourceforge authentication because it doesn't
>>>>>> provide an api to get user info so I will have to both have github and
>>>>>> sourceforge connection
>>>>>>>
>>>>>>> F.e. when a error report comes in, the server should check if it is
>>>>>>> similar (= identical) to existing reports. If it is, group them, and
>>>>>>> give the new report the same status as the existing one(s).
>>>>>>> If it is new, mark as to review, and/or send it to the bug-tracker.
>>>>>> the problem with automatic submission is spam. I think that alot of
>>>>>> error reports that are very similar but not identical would be
>>>>>> submitted if automatic submission is followed. due to the different
>>>>>> ways browsers send their stacktraces and handle errors in general some
>>>>>> reports with the same problem appear to be different thus submitted
>>>>>> individually. I think that it should be done manually when a member
>>>>>> requests it.
>>>>>
>>>>> Unless you can make a very clever system that links reports for the
>>>>> same issue, but from different browsers. ;)
>>>>>
>>>>> It's always a bit of a trade-off. Doing things automatically, reduces
>>>>> the need for human intervention (and linking similar/identical reports
>>>>> to each other can get very time consuming and cumbersome), but of
>>>>> course this might result in spam, like you mention. Time will tell (or
>>>>> after some tweaking of the link algorithm) if it can work
>>>>> automatically.
>>>>> I'd say to provide both systems (manual selection and automated linking).
>>>>
>>>> do you want any access control on the submission as well as linking on
>>>> the reports like for example only core developers or do you not mind
>>>> and want any authenticated user to do that
>>>>>
>>>>>> also should the bug submission in sourceforge come from the account of
>>>>>> the user who submitted it (requiring a sourceforge connection) or from
>>>>>> a separate account for the error reporting system which would render
>>>>>> the sourceforge connection no longer required.
>>>>>
>>>>> Bug reports will be anonymous anyway, so they can't be linked to an
>>>>> account. I'd say to use a fixed account for the error reporting
>>>>> system.
>>>> I think error reports need an account on sourceforg so they are not
>>>> exactly anonymous but I will see what I can do
>>>
>>> I meant that the error reports by the pma-client are anonymous, so
>>> using the account of the original reporter to create a ticket in the
>>> sourceforge bug tracker is not possible.
>>> Using the account of the developer who transfers the error report to
>>> the bugtracker does not make that much sense, because that person is
>>> not the one who experienced the error and is not the one to ask
>>> questions about how to reproduce, etc.
>>> So if possible, we could use an account for the error reporting
>>> system, to clearly indicate that it is an anonymous/automatic bug
>>> report, not one done by a person.
>>>
>> ok I understand now. I am actually still in contact with the support
>> staff at sourceforge about how to implement the authorisation using
>> their api. They seem oddly unhelpful however since the docs are not
>> clear enough for me in order to implement the authentication I have no
>> choice but to wait for them to answer with something a bit more
>> helpful.
>
> Did you open a ticket at the sourceforge support site? Can you send the url?
https://sourceforge.net/p/forge/site-support/4618/
>
> While waiting for the sourceforge support to provide information, you
> can start working on other things in your schedule and implement the
> sf authentication later.
I am working on  completing github authentication which was my task
for the week. I wanted to finish the sourceforge connect this week too
but maybe I will take some of the tasks from next week and do them
this week.
>
> --
> Kind regards,
>
> Dieter Adriaenssens
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Phpmyadmin-devel mailing list
> Phpmyadmin-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel