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;
From: mohamed.ashraf.213@gmail.com Date: Fri, 5 Jul 2013 19:53:29 +0200 To: phpmyadmin-devel@lists.sourceforge.net Subject: [Phpmyadmin-devel] Error reports
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.
It would be useful to subscribe to single reports by mail. The system would send a notification mail to all subscribers for a report, whenever its status is updated, or a new comment is made, etc.
It might also be useful (though not a must) to have RSS feeds per report.
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 plan for linking reports to other reports? Like: "Related reports [add]"
Do report comments support inline syntax (preferably Markdown)?
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;
I suggest you to take a look at the statuses available in the bug tracker at SF.net:
open pending resolved invalid fixed (though not sure if that's === resolved) duplicate works-for-me wont-fix out-of-date
Marking them as resolved is fine (for archiving purposes), I think we should be able to assign the version number in which we fix the bug. In the bug tracker at SF, we do this by prefixing the subject with "(ok 4.x)", but that's more of a workaround.
Don't want to put too many of my ideas on you, though. Be creative, and try to think from the phpMyAdmin developers point of view, as we are the ones who will be using the system! :)
- JM phpMyAdmin team member
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
2013/7/5 Mohamed Ashraf mohamed.ashraf.213@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.
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.
So statuses could be new/unreviewed, open (bug-tracker ticket is still open), resolved (bug was fixed).
[0] http://sourceforge.net/p/phpmyadmin/bugs/
-- Kind regards,
Dieter Adriaenssens
On Sun, Jul 7, 2013 at 12:34 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/5 Mohamed Ashraf mohamed.ashraf.213@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.
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.
So statuses could be new/unreviewed, open (bug-tracker ticket is still open), resolved (bug was fixed).
[0] http://sourceforge.net/p/phpmyadmin/bugs/
-- Kind regards,
Dieter Adriaenssens
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
From: mohamed.ashraf.213@gmail.com Date: Sun, 7 Jul 2013 15:10:48 +0200 To: phpmyadmin-devel@lists.sourceforge.net Subject: Re: [Phpmyadmin-devel] Error reports
On Sun, Jul 7, 2013 at 12:34 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/5 Mohamed Ashraf mohamed.ashraf.213@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
You might want to take a look at the Allura API [1]. As far as I can see, you have OAuth for authenticating there. Am I overlooking something?
[1] https://sourceforge.net/p/forge/documentation/Allura%20API/
JM
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.
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.
So statuses could be new/unreviewed, open (bug-tracker ticket is still open), resolved (bug was fixed).
[0] http://sourceforge.net/p/phpmyadmin/bugs/
-- Kind regards,
Dieter Adriaenssens
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
2013/7/7 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Sun, Jul 7, 2013 at 12:34 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/5 Mohamed Ashraf mohamed.ashraf.213@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).
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.
So statuses could be new/unreviewed, open (bug-tracker ticket is still open), resolved (bug was fixed).
-- Kind regards,
Dieter Adriaenssens
On Mon, Jul 8, 2013 at 4:33 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/7 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Sun, Jul 7, 2013 at 12:34 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/5 Mohamed Ashraf mohamed.ashraf.213@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
So statuses could be new/unreviewed, open (bug-tracker ticket is still open), resolved (bug was fixed).
-- Kind regards,
Dieter Adriaenssens
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
2013/7/8 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Mon, Jul 8, 2013 at 4:33 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/7 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Sun, Jul 7, 2013 at 12:34 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/5 Mohamed Ashraf mohamed.ashraf.213@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.
-- Kind regards,
Dieter Adriaenssens
On Mon, Jul 8, 2013 at 5:56 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/8 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Mon, Jul 8, 2013 at 4:33 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/7 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Sun, Jul 7, 2013 at 12:34 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/5 Mohamed Ashraf mohamed.ashraf.213@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.
-- Kind regards,
Dieter Adriaenssens
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
2013/7/8 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Mon, Jul 8, 2013 at 5:56 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/8 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Mon, Jul 8, 2013 at 4:33 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/7 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Sun, Jul 7, 2013 at 12:34 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/5 Mohamed Ashraf mohamed.ashraf.213@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?
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.
-- Kind regards,
Dieter Adriaenssens
On Tue, Jul 9, 2013 at 10:53 AM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/8 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Mon, Jul 8, 2013 at 5:56 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/8 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Mon, Jul 8, 2013 at 4:33 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/7 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Sun, Jul 7, 2013 at 12:34 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote: > 2013/7/5 Mohamed Ashraf mohamed.ashraf.213@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.clk... _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
2013/7/9 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Tue, Jul 9, 2013 at 10:53 AM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/8 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Mon, Jul 8, 2013 at 5:56 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/8 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Mon, Jul 8, 2013 at 4:33 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/7 Mohamed Ashraf mohamed.ashraf.213@gmail.com: > On Sun, Jul 7, 2013 at 12:34 PM, Dieter Adriaenssens > dieter.adriaenssens@gmail.com wrote: >> 2013/7/5 Mohamed Ashraf mohamed.ashraf.213@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?
From what I read here, I understand that you have some experience with OAuth.
Although the example on the sourceforge webpage uses a python library, there is also one for php [0]. Did you try that one?
I think it is best you use a library, not only because the sourceforge dev team suggests it, but because readability/maintainability of the code would be better. This way you don't have to write similar code than what the library already does. By using an existing library the maintenance and bugfixing is done by the maintainers of that library, so we can benefit from it.
What do you think?
[0] http://be1.php.net/manual/en/class.oauth.php
Kind regards,
Dieter
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.
On Wed, Jul 10, 2013 at 12:04 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/9 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Tue, Jul 9, 2013 at 10:53 AM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/8 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Mon, Jul 8, 2013 at 5:56 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/8 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Mon, Jul 8, 2013 at 4:33 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote: > 2013/7/7 Mohamed Ashraf mohamed.ashraf.213@gmail.com: >> On Sun, Jul 7, 2013 at 12:34 PM, Dieter Adriaenssens >> dieter.adriaenssens@gmail.com wrote: >>> 2013/7/5 Mohamed Ashraf mohamed.ashraf.213@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?
From what I read here, I understand that you have some experience with OAuth.
Although the example on the sourceforge webpage uses a python library, there is also one for php [0]. Did you try that one?
I think it is best you use a library, not only because the sourceforge dev team suggests it, but because readability/maintainability of the code would be better. This way you don't have to write similar code than what the library already does. By using an existing library the maintenance and bugfixing is done by the maintainers of that library, so we can benefit from it.
What do you think?
ok, with further reading it seems that they are using a different version from oauth than the one that I have been used to. It looks more complicated than usual which I think is why they wanted me to use the library. I didnt know there is a php class, that could smooth things over. I will try to use the class within my code.
The reason I did not want to use the library is because the oauth authorizations that I have been used to (OAuth v2.0) didnt require anything other than redirects and json decode which was simple to implement. I actually created a component in cakephp to do the hard work make the code more readable. however it seems that this oauth implementation (OAuth v1.0) requires sending the params in the headers which is why a library required.
I always new there were two versions of oauth but I didn't realize they were so different.
[0] http://be1.php.net/manual/en/class.oauth.php
Kind regards,
Dieter
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.
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.clk... _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
2013/7/10 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Wed, Jul 10, 2013 at 12:04 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/9 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Tue, Jul 9, 2013 at 10:53 AM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/8 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Mon, Jul 8, 2013 at 5:56 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/7/8 Mohamed Ashraf mohamed.ashraf.213@gmail.com: > On Mon, Jul 8, 2013 at 4:33 PM, Dieter Adriaenssens > dieter.adriaenssens@gmail.com wrote: >> 2013/7/7 Mohamed Ashraf mohamed.ashraf.213@gmail.com: >>> On Sun, Jul 7, 2013 at 12:34 PM, Dieter Adriaenssens >>> dieter.adriaenssens@gmail.com wrote: >>>> 2013/7/5 Mohamed Ashraf mohamed.ashraf.213@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?
From what I read here, I understand that you have some experience with OAuth.
Although the example on the sourceforge webpage uses a python library, there is also one for php [0]. Did you try that one?
I think it is best you use a library, not only because the sourceforge dev team suggests it, but because readability/maintainability of the code would be better. This way you don't have to write similar code than what the library already does. By using an existing library the maintenance and bugfixing is done by the maintainers of that library, so we can benefit from it.
What do you think?
ok, with further reading it seems that they are using a different version from oauth than the one that I have been used to. It looks more complicated than usual which I think is why they wanted me to use the library. I didnt know there is a php class, that could smooth things over. I will try to use the class within my code.
Ok, good that you found this out. I guess it should get you going now.
I read that for actual accessing a project, you will need an access token. If a test tracker needs to be set up, please let us know.
Happy coding!
The reason I did not want to use the library is because the oauth authorizations that I have been used to (OAuth v2.0) didnt require anything other than redirects and json decode which was simple to implement. I actually created a component in cakephp to do the hard work make the code more readable. however it seems that this oauth implementation (OAuth v1.0) requires sending the params in the headers which is why a library required.
I always new there were two versions of oauth but I didn't realize they were so different.
[0] http://be1.php.net/manual/en/class.oauth.php
Kind regards,
Dieter
-- Kind regards,
Dieter Adriaenssens
-
Dieter Adriaenssens -
J. M. -
Mohamed Ashraf