GSoC 2017 - Project "Onionoo"
Hi! I’m Nur-Magomed Dzhamiev, 4th year student from institute of information technology (speciality: computer security) of North-Caucasus Federal University. I have experience with Java, SQL, Web (HTML, CSS, JavaScript, PHP) and also I designed protocol based on JSON for Android app. I would love to contribute to the project "Onionoo". Please provide me some guide lines and additional materials for study and get a clear understanding about the mentioned project. Thank you! Regards Nur-Magomed
Hi Nur-Magomed. Unfortunately the folks maintaining Onionoo are unavailable to mentor this summer. I'd suggest looking into another subproject. On Tue, Mar 14, 2017 at 10:59 AM, Nur-Magomed <nmagoru@gmail.com> wrote:
Hi!
I’m Nur-Magomed Dzhamiev, 4th year student from institute of information technology (speciality: computer security) of North-Caucasus Federal University. I have experience with Java, SQL, Web (HTML, CSS, JavaScript, PHP) and also I designed protocol based on JSON for Android app.
I would love to contribute to the project "Onionoo". Please provide me some guide lines and additional materials for study and get a clear understanding about the mentioned project. Thank you!
Regards
Nur-Magomed
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
It's a pity. Could you provide me some guide lines and additional materials for project "ExoneraTor", I also interested to work with that 2017-03-14 22:27 GMT+03:00 Damian Johnson <atagar@torproject.org>:
Hi Nur-Magomed. Unfortunately the folks maintaining Onionoo are unavailable to mentor this summer. I'd suggest looking into another subproject.
On Tue, Mar 14, 2017 at 10:59 AM, Nur-Magomed <nmagoru@gmail.com> wrote:
Hi!
I’m Nur-Magomed Dzhamiev, 4th year student from institute of information technology (speciality: computer security) of North-Caucasus Federal University. I have experience with Java, SQL, Web (HTML, CSS, JavaScript, PHP) and also I designed protocol based on JSON for Android app.
I would love to contribute to the project "Onionoo". Please provide me some guide lines and additional materials for study and get a clear understanding about the mentioned project. Thank you!
Regards
Nur-Magomed
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ExoneraTor is in the same boat. The metrics team are the ones that are unavailable so everything they own (Onionoo, Atlas, Metrics-Lib, ExoneraTor, etc) would be poor choices. You're more than welcome to propose your own project idea but if so you'll need to find a mentor in our community. If you'd care for projects with mentors already available then please see... https://www.torproject.org/getinvolved/volunteer.html.en#Coding On 3/14/17, Nur-Magomed <nmagoru@gmail.com> wrote:
It's a pity. Could you provide me some guide lines and additional materials for project "ExoneraTor", I also interested to work with that
2017-03-14 22:27 GMT+03:00 Damian Johnson <atagar@torproject.org>:
Hi Nur-Magomed. Unfortunately the folks maintaining Onionoo are unavailable to mentor this summer. I'd suggest looking into another subproject.
On Tue, Mar 14, 2017 at 10:59 AM, Nur-Magomed <nmagoru@gmail.com> wrote:
Hi!
I’m Nur-Magomed Dzhamiev, 4th year student from institute of information technology (speciality: computer security) of North-Caucasus Federal University. I have experience with Java, SQL, Web (HTML, CSS, JavaScript, PHP) and also I designed protocol based on JSON for Android app.
I would love to contribute to the project "Onionoo". Please provide me some guide lines and additional materials for study and get a clear understanding about the mentioned project. Thank you!
Regards
Nur-Magomed
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi! I'm interesred with project "Crash Reporter for Tor Browser". I'm working on that idea, but I need some specifications about how it should work, what kind of crash information we have to get and what technologies I can use on server side (for collect information). 2017-03-14 22:51 GMT+03:00 Damian Johnson <atagar@torproject.org>:
ExoneraTor is in the same boat. The metrics team are the ones that are unavailable so everything they own (Onionoo, Atlas, Metrics-Lib, ExoneraTor, etc) would be poor choices.
You're more than welcome to propose your own project idea but if so you'll need to find a mentor in our community. If you'd care for projects with mentors already available then please see...
https://www.torproject.org/getinvolved/volunteer.html.en#Coding
On 3/14/17, Nur-Magomed <nmagoru@gmail.com> wrote:
It's a pity. Could you provide me some guide lines and additional materials for project "ExoneraTor", I also interested to work with that
2017-03-14 22:27 GMT+03:00 Damian Johnson <atagar@torproject.org>:
Hi Nur-Magomed. Unfortunately the folks maintaining Onionoo are unavailable to mentor this summer. I'd suggest looking into another subproject.
On Tue, Mar 14, 2017 at 10:59 AM, Nur-Magomed <nmagoru@gmail.com> wrote:
Hi!
I’m Nur-Magomed Dzhamiev, 4th year student from institute of information technology (speciality: computer security) of North-Caucasus Federal University. I have experience with Java, SQL, Web (HTML, CSS, JavaScript, PHP) and also I designed protocol based on JSON for Android app.
I would love to contribute to the project "Onionoo". Please provide me some guide lines and additional materials for study and get a clear understanding about the mentioned project. Thank you!
Regards
Nur-Magomed
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 19 Mar 2017, at 19:02, Nur-Magomed <nmagoru@gmail.com> wrote:
Hi! I'm interesred with project "Crash Reporter for Tor Browser". I'm working on that idea, but I need some specifications about how it should work, what kind of crash information we have to get and what technologies I can use on server side (for collect information). ...
Hi Nur-Magomed, I've cc'd the mentors for the Crash Reporter project on this email. Please be aware that we have a meeting this week and next week, so some of us are busy travelling and working together in person. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
Hi Nur-Magomed, Great to have you interested in this! So we would want to use the Crash Reporter that's built into Mozilla Firefox (which is called Breakpad, and is adapted from Chromium). At a high level, I would break down the project into the following sections: 1) Get the crash reporter built (at all) in our toolchain. We currently disable it and I know there will be at least one or two hurdles to overcome here as we've never tried to built this on Linux-for-Windows. If you wish you could focus on a single platform for this at a time (e.g. Linux) so you can move onto the next step. 2) Audit the crash reporter data and see what it is that gets reported, when, and how. We'd want to err on the side of caution about what we report in a dump. So we'd need to enumerate each field that gets reported, get some samples of the data, and review if we'd want to include it or not. We'd also want to review what prefs govern crash submissions, how crashes get stored (which I think is on-disk next to Tor Browser), and when they get reported. 3) Change the way they get reported. We absolutely cannot have crashes sitting around on disk next to Tor Browser for the next time the user starts the browser - no matter how much data we strip out of them. So we'll need to brainstorm how we might try submitting them immediately upon crash instead of next startup. 4) Get a submission server running. Mozilla has a ton of tools to analyze crashes (https://crash-stats.mozilla.org/home/product/Firefox is one and https://github.com/mozilla/socorro is the general backend). We should look at Socorro and probably adapt it for use by Tor rather than building our own. 5) Circle back and get the crash reporter built reproducibly, and for all platforms. I put this one last because it may be the case that there are annoying time-sinks here, and I think by doing this last you'll be able to make the most headway on things that will take the most time - like enumerating, documenting, and evaluating the fields; and fiddling with Socorro. This is my take on it - Georg may have additional thoughts. -tom On 20 March 2017 at 09:01, teor <teor2345@gmail.com> wrote:
On 19 Mar 2017, at 19:02, Nur-Magomed <nmagoru@gmail.com> wrote:
Hi! I'm interesred with project "Crash Reporter for Tor Browser". I'm working on that idea, but I need some specifications about how it should work, what kind of crash information we have to get and what technologies I can use on server side (for collect information). ...
Hi Nur-Magomed,
I've cc'd the mentors for the Crash Reporter project on this email.
Please be aware that we have a meeting this week and next week, so some of us are busy travelling and working together in person.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
Hi Tom, Thank you for the response! I’ve started to dive in process, collecting information about BreakPad and Socorro. Also I created the blog for project - https://torcrashreporter.wordpress.com. In few days I'll try to send draft of proposal. Regards Nur-Magomed 2017-03-20 18:18 GMT+03:00 Tom Ritter <tom@ritter.vg>:
Hi Nur-Magomed,
Great to have you interested in this!
So we would want to use the Crash Reporter that's built into Mozilla Firefox (which is called Breakpad, and is adapted from Chromium). At a high level, I would break down the project into the following sections:
1) Get the crash reporter built (at all) in our toolchain. We currently disable it and I know there will be at least one or two hurdles to overcome here as we've never tried to built this on Linux-for-Windows. If you wish you could focus on a single platform for this at a time (e.g. Linux) so you can move onto the next step.
2) Audit the crash reporter data and see what it is that gets reported, when, and how. We'd want to err on the side of caution about what we report in a dump. So we'd need to enumerate each field that gets reported, get some samples of the data, and review if we'd want to include it or not. We'd also want to review what prefs govern crash submissions, how crashes get stored (which I think is on-disk next to Tor Browser), and when they get reported.
3) Change the way they get reported. We absolutely cannot have crashes sitting around on disk next to Tor Browser for the next time the user starts the browser - no matter how much data we strip out of them. So we'll need to brainstorm how we might try submitting them immediately upon crash instead of next startup.
4) Get a submission server running. Mozilla has a ton of tools to analyze crashes (https://crash-stats.mozilla.org/home/product/Firefox is one and https://github.com/mozilla/socorro is the general backend). We should look at Socorro and probably adapt it for use by Tor rather than building our own.
5) Circle back and get the crash reporter built reproducibly, and for all platforms. I put this one last because it may be the case that there are annoying time-sinks here, and I think by doing this last you'll be able to make the most headway on things that will take the most time - like enumerating, documenting, and evaluating the fields; and fiddling with Socorro.
This is my take on it - Georg may have additional thoughts.
-tom
On 20 March 2017 at 09:01, teor <teor2345@gmail.com> wrote:
On 19 Mar 2017, at 19:02, Nur-Magomed <nmagoru@gmail.com> wrote:
Hi! I'm interesred with project "Crash Reporter for Tor Browser". I'm working on that idea, but I need some specifications about how it
should work, what kind of crash information we have to get and what technologies I can use on server side (for collect information).
...
Hi Nur-Magomed,
I've cc'd the mentors for the Crash Reporter project on this email.
Please be aware that we have a meeting this week and next week, so some of us are busy travelling and working together in person.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Tom Ritter:
Hi Nur-Magomed,
Great to have you interested in this!
So we would want to use the Crash Reporter that's built into Mozilla Firefox (which is called Breakpad, and is adapted from Chromium). At a high level, I would break down the project into the following sections:
Those look all good to me. I just have one small addition/clarification below.
1) Get the crash reporter built (at all) in our toolchain. We currently disable it and I know there will be at least one or two hurdles to overcome here as we've never tried to built this on Linux-for-Windows. If you wish you could focus on a single platform for this at a time (e.g. Linux) so you can move onto the next step.
2) Audit the crash reporter data and see what it is that gets reported, when, and how. We'd want to err on the side of caution about what we report in a dump. So we'd need to enumerate each field that gets reported, get some samples of the data, and review if we'd want to include it or not. We'd also want to review what prefs govern crash submissions, how crashes get stored (which I think is on-disk next to Tor Browser), and when they get reported.
3) Change the way they get reported. We absolutely cannot have crashes sitting around on disk next to Tor Browser for the next time the user starts the browser - no matter how much data we strip out of them. So we'll need to brainstorm how we might try submitting them immediately upon crash instead of next startup.
Even though it seems to me the critical UX part is implicit in the section above, I thought it might be better to point it out explicitly as well: We should have a good user interface ready giving the user at least an explanation on what is going on and a way to check what is about to be sent. Georg
4) Get a submission server running. Mozilla has a ton of tools to analyze crashes (https://crash-stats.mozilla.org/home/product/Firefox is one and https://github.com/mozilla/socorro is the general backend). We should look at Socorro and probably adapt it for use by Tor rather than building our own.
5) Circle back and get the crash reporter built reproducibly, and for all platforms. I put this one last because it may be the case that there are annoying time-sinks here, and I think by doing this last you'll be able to make the most headway on things that will take the most time - like enumerating, documenting, and evaluating the fields; and fiddling with Socorro.
This is my take on it - Georg may have additional thoughts.
-tom
Hi, Georg, Thank you!
We should have a good user interface ready giving the user at least an explanation on what is going on and a way to check what is about to be sent.
I've also thought about that, I suppose we could just put text explanations on Crash Reporter client UI form [1]. I've wrote the Proposal [2], could you review it and leave comments? Thanks. P.S. Have I to send proposal to GSoc as draft? 1) http://kb.mozillazine.org/images/MozillaCrashReporter-Fx7.png 2) https://docs.google.com/document/d/13q3D1UYYbmUv4DlZBYFLnHuLnbz7-GI2L_lMM9ig... 2017-03-26 18:23 GMT+03:00 Georg Koppen <gk@torproject.org>:
Tom Ritter:
Hi Nur-Magomed,
Great to have you interested in this!
So we would want to use the Crash Reporter that's built into Mozilla Firefox (which is called Breakpad, and is adapted from Chromium). At a high level, I would break down the project into the following sections:
Those look all good to me. I just have one small addition/clarification below.
1) Get the crash reporter built (at all) in our toolchain. We currently disable it and I know there will be at least one or two hurdles to overcome here as we've never tried to built this on Linux-for-Windows. If you wish you could focus on a single platform for this at a time (e.g. Linux) so you can move onto the next step.
2) Audit the crash reporter data and see what it is that gets reported, when, and how. We'd want to err on the side of caution about what we report in a dump. So we'd need to enumerate each field that gets reported, get some samples of the data, and review if we'd want to include it or not. We'd also want to review what prefs govern crash submissions, how crashes get stored (which I think is on-disk next to Tor Browser), and when they get reported.
3) Change the way they get reported. We absolutely cannot have crashes sitting around on disk next to Tor Browser for the next time the user starts the browser - no matter how much data we strip out of them. So we'll need to brainstorm how we might try submitting them immediately upon crash instead of next startup.
Even though it seems to me the critical UX part is implicit in the section above, I thought it might be better to point it out explicitly as well:
We should have a good user interface ready giving the user at least an explanation on what is going on and a way to check what is about to be sent.
Georg
4) Get a submission server running. Mozilla has a ton of tools to analyze crashes (https://crash-stats.mozilla.org/home/product/Firefox is one and https://github.com/mozilla/socorro is the general backend). We should look at Socorro and probably adapt it for use by Tor rather than building our own.
5) Circle back and get the crash reporter built reproducibly, and for all platforms. I put this one last because it may be the case that there are annoying time-sinks here, and I think by doing this last you'll be able to make the most headway on things that will take the most time - like enumerating, documenting, and evaluating the fields; and fiddling with Socorro.
This is my take on it - Georg may have additional thoughts.
-tom
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 28 March 2017 at 16:22, Nur-Magomed <nmagoru@gmail.com> wrote:
Hi, Georg, Thank you!
We should have a good user interface ready giving the user at least an explanation on what is going on and a way to check what is about to be sent.
I've also thought about that, I suppose we could just put text explanations on Crash Reporter client UI form [1].
I think we'd want to enhance this form. IIRC the 'Details' view is small and obtuse and it's not easy to review. I'm not saying we _should_ create these features, but here are a few I brainstormed: - A much bigger, more clear Details window with: - The ability to include to exclude individual sections of the report (for example, Hardware information would not be included by default, but maybe we give the user the ability to include it) - The ability to perform text searches for keywords of their choosing to spot-check if they are present in the report Just ideas.
I've wrote the Proposal [2], could you review it and leave comments? Thanks.
Let's try and avoid GDocs if you don't mind :) I put your document here: https://storm.torproject.org/shared/DHc8GjUYr8aUNeO2ZcOjTc1xG3pwbburIQoLYB9w... (I don't know if you can create storm documents, but you could use pad.riseup.net ) and put comments on it.
P.S. Have I to send proposal to GSoc as draft?
I don't know the answer to this, but hopefully Damian does? -tom
P.S. Have I to send proposal to GSoc as draft?
I don't know the answer to this, but hopefully Damian does?
It would be useful if you uploaded a draft to the site, but really the only hard requirement is that the proposal is uploaded before the deadline. ;)
I think we'd want to enhance this form. IIRC the 'Details' view is small and obtuse and it's not easy to review. I'm not saying we _should_ create these features, but here are a few I brainstormed:
Yes, actually that form only shows "Key: Value" list, we can break it down in several GroupBoxes which consist of grouped data field and checkboxes to include.
Let's try and avoid GDocs if you don't mind :)
Sorry :) I already registered on storm, but I had no access to create. Thanks for review, I'll update proposal accordint to your requiments. And question: could we throw Windows or MacOS or both versions from timeline, and develop them after summer? 2017-03-31 0:44 GMT+03:00 Damian Johnson <atagar@torproject.org>:
P.S. Have I to send proposal to GSoc as draft?
I don't know the answer to this, but hopefully Damian does?
It would be useful if you uploaded a draft to the site, but really the only hard requirement is that the proposal is uploaded before the deadline. ;) _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 31 March 2017 at 10:27, Nur-Magomed <nmagoru@gmail.com> wrote:
I think we'd want to enhance this form. IIRC the 'Details' view is small and obtuse and it's not easy to review. I'm not saying we _should_ create these features, but here are a few I brainstormed:
Yes, actually that form only shows "Key: Value" list, we can break it down in several GroupBoxes which consist of grouped data field and checkboxes to include.
Let's try and avoid GDocs if you don't mind :)
Sorry :) I already registered on storm, but I had no access to create. Thanks for review, I'll update proposal accordint to your requiments.
No worries.
And question: could we throw Windows or MacOS or both versions from timeline, and develop them after summer?
Yes, I think that's fine. I think getting one platform to completion would be a great accomplishment and would lay the groundwork and improve the momentum to getting the subsequent platforms there. -tom
Hi Tom, I've updated Proposal[1] according to your recommendations. 1) https://storm.torproject.org/grain/ECCJ3Taeq93qCvPJoWJkkY/ 2017-03-31 19:46 GMT+03:00 Tom Ritter <tom@ritter.vg>:
On 31 March 2017 at 10:27, Nur-Magomed <nmagoru@gmail.com> wrote:
I think we'd want to enhance this form. IIRC the 'Details' view is small and obtuse and it's not easy to review. I'm not saying we _should_ create these features, but here are a few I brainstormed:
Yes, actually that form only shows "Key: Value" list, we can break it down in several GroupBoxes which consist of grouped data field and checkboxes to include.
Let's try and avoid GDocs if you don't mind :)
Sorry :) I already registered on storm, but I had no access to create. Thanks for review, I'll update proposal accordint to your requiments.
No worries.
And question: could we throw Windows or MacOS or both versions from timeline, and develop them after summer?
Yes, I think that's fine. I think getting one platform to completion would be a great accomplishment and would lay the groundwork and improve the momentum to getting the subsequent platforms there.
-tom _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 1 April 2017 at 09:22, Nur-Magomed <nmagoru@gmail.com> wrote:
Hi Tom, I've updated Proposal[1] according to your recommendations.
1) https://storm.torproject.org/grain/ECCJ3Taeq93qCvPJoWJkkY/
Looks good to me!
2017-03-31 19:46 GMT+03:00 Tom Ritter <tom@ritter.vg>:
On 31 March 2017 at 10:27, Nur-Magomed <nmagoru@gmail.com> wrote:
I think we'd want to enhance this form. IIRC the 'Details' view is small and obtuse and it's not easy to review. I'm not saying we _should_ create these features, but here are a few I brainstormed:
Yes, actually that form only shows "Key: Value" list, we can break it down in several GroupBoxes which consist of grouped data field and checkboxes to include.
Let's try and avoid GDocs if you don't mind :)
Sorry :) I already registered on storm, but I had no access to create. Thanks for review, I'll update proposal accordint to your requiments.
No worries.
And question: could we throw Windows or MacOS or both versions from timeline, and develop them after summer?
Yes, I think that's fine. I think getting one platform to completion would be a great accomplishment and would lay the groundwork and improve the momentum to getting the subsequent platforms there.
-tom _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
It would be cool to build the browser with https://github.com/google/sanitizers this way you could get bug reports for bugs that don't panic the browser Il lun 3 apr 2017, 07:10 Tom Ritter <tom@ritter.vg> ha scritto:
On 1 April 2017 at 09:22, Nur-Magomed <nmagoru@gmail.com> wrote:
Hi Tom, I've updated Proposal[1] according to your recommendations.
1) https://storm.torproject.org/grain/ECCJ3Taeq93qCvPJoWJkkY/
Looks good to me!
2017-03-31 19:46 GMT+03:00 Tom Ritter <tom@ritter.vg>:
On 31 March 2017 at 10:27, Nur-Magomed <nmagoru@gmail.com> wrote:
I think we'd want to enhance this form. IIRC the 'Details' view is small and obtuse and it's not easy to review. I'm not saying we _should_ create these features, but here are a few I brainstormed:
Yes, actually that form only shows "Key: Value" list, we can break it down in several GroupBoxes which consist of grouped data field and
checkboxes
to include.
Let's try and avoid GDocs if you don't mind :)
Sorry :) I already registered on storm, but I had no access to create. Thanks for review, I'll update proposal accordint to your requiments.
No worries.
And question: could we throw Windows or MacOS or both versions from timeline, and develop them after summer?
Yes, I think that's fine. I think getting one platform to completion would be a great accomplishment and would lay the groundwork and improve the momentum to getting the subsequent platforms there.
-tom _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Tom, thanks for review, I've sent the proposal final version through gsoc site. __
It would be cool to build the browser with https://github.com/google/sani tizers this way you could get bug reports for bugs that don't >panic the browser
Hi Antonio, Thanks for your reply! I've add it to the proposal as optional. 2017-04-03 8:42 GMT+03:00 Antonio Groza <antoniogroza@gmail.com>:
It would be cool to build the browser with https://github.com/google/sani tizers this way you could get bug reports for bugs that don't panic the browser
Il lun 3 apr 2017, 07:10 Tom Ritter <tom@ritter.vg> ha scritto:
On 1 April 2017 at 09:22, Nur-Magomed <nmagoru@gmail.com> wrote:
Hi Tom, I've updated Proposal[1] according to your recommendations.
1) https://storm.torproject.org/grain/ECCJ3Taeq93qCvPJoWJkkY/
Looks good to me!
2017-03-31 19:46 GMT+03:00 Tom Ritter <tom@ritter.vg>:
On 31 March 2017 at 10:27, Nur-Magomed <nmagoru@gmail.com> wrote:
I think we'd want to enhance this form. IIRC the 'Details' view is small and obtuse and it's not easy to review. I'm not saying we _should_ create these features, but here are a few I brainstormed:
Yes, actually that form only shows "Key: Value" list, we can break it down in several GroupBoxes which consist of grouped data field and
checkboxes
to include.
Let's try and avoid GDocs if you don't mind :)
Sorry :) I already registered on storm, but I had no access to create. Thanks for review, I'll update proposal accordint to your requiments.
No worries.
And question: could we throw Windows or MacOS or both versions from timeline, and develop them after summer?
Yes, I think that's fine. I think getting one platform to completion would be a great accomplishment and would lay the groundwork and improve the momentum to getting the subsequent platforms there.
-tom _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (6)
-
Antonio Groza -
Damian Johnson -
Georg Koppen -
Nur-Magomed -
teor -
Tom Ritter