htrace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nisala Mendis <nisal...@gmail.com>
Subject Re-evaluation of GSoC Final Evaluation Result ( Apache Htrace Kudu Backend )
Date Tue, 30 Aug 2016 07:47:04 GMT
Hi Google Support,

I just got received my mentors evaluation and I would like request Google
to kindly reevaluate my final outcome. I would like to point out my mentors
each evaluation each point into you kind consideration.

I am sorry that the project seems to have failed. I mentioned on the
midterm evaluation that I was concerned about the lack of progress on the
project, and unfortunately the pace only got slower after that. I think
that the biggest problem that we had was that you simply did not dedicate
enough time to the project to succeed. When we were in the project
selection phase, you said that you could dedicate 35 hours a week to the
project. However, this turned out to be a wild overestimate. I doubt that
you spent more than 5 hours a week during any week, and for many weeks,

First of all my mentor I would like to mention my mentor has never spent
with me at lease one or two hour each week. Even  though we have agreed to
share the status by each twice week, he has always ask for status without
even let me what to do with my project without any guidance. Sometime I got
even stuck he has never even shed  light, right from the beginning I
learned their project deployment, and I worked out their development
environment from my own. Apache htrace is still incubator process doesnt
even have proper documentation. Expectation from my mentor is unacceptable
under this conditions. He always say "You need to ask questions" If you can
read until last of my mentor evaluation , he even himself agreed that even
at last moment I have worked towards completion of project. There s not
much left in this project. Theres no way one can do that without working at
5 hour per week. And

you seem to have spent 0 hours-- not even bothering to respond to emails or
send a status update. It's very frustrating when a student becomes
uncommunicative for almost a full month at a time.

This is a complete false statement I have never been in active for full one
month. I have only been inactive maximum close  for two weeks. This is
personal mail Colin my mentor and we agreed to move on. After two weeks
inactivity this is the email I got from my mentor,


Hi Nisala,

You've been unresponsive for half a month.  I'm concerned about the
project.  Frankly I feel like we might not have time to finish now,
since you took such a long unannounced break in the middle.  The final
evaluation is on August 15th.  Let's think about this more and how we
could prevent it from happening again in the future.

best,

Colin

This is his personal mail from him for my maximum inactivity for two weeks
and we agreed to move on by JULY 19.

My single biggest suggestion for improvement is to respond promptly when
other people try to communicate, and to stick to pre-agreed schedules of
project updates and meetings.

First of all we agreed only share status on emails we never had meetings,
we have never scheduled meetings.

This is the email from my mentor that we agreed to share status by only
mail. This is on Fri, May 6 during community bonding period.


Hmm.  Video calls seem to be difficult, owing to the time difference and
some of the technical issues.

Instead, how about we exchange status emails two times a week.  Monday and
Thursday seem like good days to email.

I'll start.

A big part of Google Summer of Code is learning to interact with the
community and learn some things about the project.

I have only communicated my status updates via JIRA ticket [1]
https://issues.apache.org/jira/browse/HTRACE-362 where all community sees
my project. You will notice I have completed his reviews which has put
during the final GSOC mentor evaluation period. Because we both agreed to
successfully completion in earlier.

When you try to complete a large portion of the code just a few days before
the end of GSoC, the community has no time to review it, let alone discuss
it. Code review takes time. It's also very important to respond to all the
comments people make in a code review. I remember having to make the same
comments several times before you would address them.

What I wanted to highlight is [1]
https://issues.apache.org/jira/browse/HTRACE-362 He still adds reviews for
code that I wrote in mid term.
 If you look at [1]
https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15333197&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15333197
He has never mentioned anything about kudu schema but now adding reviews
regarding that end of the project at [2]
https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15429907&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15429907

This is totally unacceptable rather if some one want to fail that project
do something like that. I agree in one time I couldn't address his all his
requirements at once. He is keeps on adding reviews for code that I written
for midterm regarding kudu schema and handling multiple parents of spans.
He mid term code review does not include them all. Even he has failed to
answer which schema should use.

In this [1]
https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15437201&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15437201
This was his response about kudu schema, where he claims I should have
looked some other code as he claims

This is one reason why I suggested that you look at LocalFileSpanReceiver
and HTracedSpanReceiver rather than HBaseSpanReceiver.

Which is completely false statement, He has never mentioned such to me even
in that thread or personal mail. I wonder whether he could prove that to
anyone. He wanted emphasize this project failed because of me this which is
completely a false statement.

I am glad that we have at least a little code to start from when building a
Kudu spanreceiver. What we need to do to get this merged is to actually
complete all the tasks mentioned in the original proposal document--
develop a way to run the full web interface against the Kudu SpanReceiver,
write good documentation for setup and deployment, understand what the
correct schema to use to store data in Kudu is, measure performance, and
write unit tests.

This my proposal under [1]
https://docs.google.com/document/d/14pnwHj5IsstCuBG3puD0x36KSmXxnglryRsfJcWP3Kg/edit?usp=sharing
This the last update which I gave to him under comment [2]
https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15428686&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15428686

Where I have completed second part of the project which has not been
reviewed, and If he could provide the answer whether to use the webapp ( in
previous comment ) similar to HBASE this project is done done. Where we
have similar webapp for like HBASE or integrate to current main Htrace
webapp. He never given answer because He wanted look this project failed.
Even the current HBASE htrace recever has have so many limitations, He too
much expect this KUDU receiver to be PERFECT which I believe, is completely
unacceptable.

In my proposal I have never mentioned anything about performance test for
different kudu schema. Even in this main thread [1]
https://issues.apache.org/jira/browse/HTRACE-362 he has never mentioned
such. These are totally false statements. However I agree on the
documentation.

The code I written for both span receiver and span viewer have unit tests
under pr [1] https://github.com/apache/incubator-htrace/pull/11 This
completely false I have written unit tests for both  span receiver and
viewer using KUDU mini cluster utility.

I hope Google and Apache Organization Admins will reconsider my evalution
for GSoC 2016. In
[1] https://gist.github.com/nisalanirmana/9ac0b8d34ee198f4dcafc64e6f84ba5a
I have mentioned all the work that I completed. Since my mentor is first
time mentoring, He think all code should be by mentor evaluation. Which I
believe it is not the expectation.

Regards
Nisala

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