You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by Ayola Jayamaha <ra...@gmail.com> on 2015/07/03 20:06:52 UTC
Re: Working toward merge requests and commits to Phoenix
Hi,
I am working on milestone3 PR[1]. I have updated the pom mapping to the
Phoenix parent pom. I will write the launching script in Phoenix bin. I'm
progressing on making the web app standalone. As I'm progressing through
the task list I will tick them.
Let me know if I missed anything on the task list.
Thanks.
[1] https://github.com/apache/phoenix/pull/96
On Fri, Jul 3, 2015 at 8:41 AM, Ayola Jayamaha <ra...@gmail.com>
wrote:
> Hi Nick,
>
> I have created a pull request [1]. After going through the steps that you
> have given and the resources I was able to create it with no conflicts and
> it is giving a green button. So I think it is fine. If there is some
> mistake please let me know.
> Step 1 has been done. Updating the pom files are yet to be done.
>
> Thanks.
>
> [1] https://github.com/apache/phoenix/pull/96
>
> On Fri, Jul 3, 2015 at 12:46 AM, Ayola Jayamaha <ra...@gmail.com>
> wrote:
>
>> Thanks James and Nick for Quick reply.
>>
>> On Fri, Jul 3, 2015 at 12:05 AM, Nick Dimiduk <nd...@apache.org>
>> wrote:
>>
>>> * 1. Work from a fork of Phoenix, not your own project.*
>>>> Yes I know the git work flow some far. And I can get a fork from
>>>> Phoenix and do my implementation there(branch).
>>>>
>>>
>>> Great!
>>>
>>> I have created the milestone 3 branch(Phoenix 4.4 Hbase 9.8) and I have
>>>> sent the pull request and it is not completed (pom file is not pointing to
>>>> the Phoenix parent pom still). If I have done any mistake please let me
>>>> know.
>>>>
>>>> [1] https://github.com/apache/phoenix/pull/95
>>>>
>>>
>>> Yikes, this needs some git-hygeine. Your PR should contain only your
>>> changes. Please rebase your changes on top of the existing branch.
>>> Something like the following commands should suffice (assuming you have
>>> github.com/apache/phoenix as origin):
>>>
>>> $ git remote update
>>> $ git checkout nishanis-branch
>>> $ git rebase origin/4.4-HBase-0.98
>>>
>>> I will try to follow them. and try to fix it
>>
>> That should give you just your commits at the HEAD, and you can base your
>>> PR from that. We can walk through this with a screen share if you'd like, I
>>> have time today and tomorrow.
>>>
>> Thanks, If I was not able. I will share screen and get the help tomorrow
>>
>>
>>> There's a pretty good description of rebase:
>>> http://www.git-tower.com/blog/understanding-rebase-merge-in-git/
>>>
>>> * 2. Web service that is launched with a python script from bin.*
>>>> I will add a new folder in root level of Phoenix(4.4.0 9.8Hbase) called
>>>> (tracingwebapp). And when you run the build from root level(need to update
>>>> the root pom of Phoenix) or build from the folder level tracingwebapp and
>>>> it will build the war file. So I will add a launching script to the bin of
>>>> Phoenix to start the war file. Is it fine?
>>>>
>>>
>>> We'll need it integrated into Phoenix's build, so that `mvn clean
>>> package` from the Phoenix root will also build your code and run your
>>> tests. Phoenix is a "multi-module" project, which means it consists of
>>> multiple independent components. We're going to add tracingwebapp as a new
>>> component. You can see how the pom.xml file in the root of the project
>>> defines a list of modules. tracingwebapp will be added to that list.
>>>
>> Think looking on the other pom file in Phoenix. I can make it.
>>
>>>
>>> There's a text-book example of multi-module projects:
>>> http://books.sonatype.com/mvnex-book/reference/multimodule.html
>>>
>>> * 3. The tracing tools queries the real tracing table for spans.*
>>>> I have written a Java code to to read the tracing data of Phoenix and
>>>> adding it to a text file. It is not added to Jetty yet. I would be needing
>>>> help to communicate from Java to Javascript.
>>>>
>>>
>>> Excellent! We can start working on that once you have steps (1) and (2)
>>> pulled together.
>>>
>>> * 4. The UI renders those spans.*
>>>> Yes there will be issues when integrating. At the moment I have sent a
>>>> PR. I'm not sure I did it correctly.
>>>>
>>>
>>> I'm not sure which PR you mean, do you have a link?
>>>
>> That I have shared in above
>> [1] https://github.com/apache/phoenix/pull/95
>>
>> steps that I followed
>> 1. Got the fork from Apache
>> 2. Make a new branch ' milestone 3' [2] on 4.4-HBase-0.98
>>
>> [2] https://github.com/AyolaJayamaha/phoenix/tree/milestone-3
>>
>>
>>
>>>
>>> After the mid-term communicate from Java to Javascript will be the first
>>>> part. These changes will be done on the PR.
>>>>
>>>
>>> During development, it's better to work from a personal branch (which
>>> can be public on your own public github repository) instead of PR's. We can
>>> collaborate there -- you can push commits to it, we can comment on them,
>>> you can push fixes, squishing history and so on. Once your branch is in
>>> good shape, you rebase it onto the latest community changes and then
>>> publish your PR. We can practice this workflow after you've completed (1)
>>> anove.
>>>
>> ok
>>
>>>
>>> On Wed, Jul 1, 2015 at 10:28 PM, James Taylor <ja...@apache.org>
>>>> wrote:
>>>>
>>>>> I second what Nick said - we need to be driving the UI directly from
>>>>> Phoenix queries against the trace table. I think with #3, one valuable
>>>>> output will be a series of Phoenix queries that provide insight into
>>>>> understanding the performance of a query.
>>>>>
>>>>> Unfortunately, what you've done so far isn't helping Phoenix. This
>>>>> needs to be fixed quickly, or we've failed in my mind.
>>>>>
>>>>> Are you working full-time on this, Nishani?
>>>>>
>>>>> Thanks,
>>>>> James
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 30, 2015 at 12:16 PM, Nick Dimiduk <nd...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Hi Nishani,
>>>>>>
>>>>>> I'm glad to see your self-modivation and continued progress. UI
>>>>>> development is not my strength, and I like how you've interacted with the
>>>>>> community to solicit feedback through your prototyping stages. One thing we
>>>>>> are concerned about is your project coming to a point where it's ready to
>>>>>> be committed back to Phoenix. I think it would be a real shame for you and
>>>>>> for Apache if your work is not merged into the project.
>>>>>>
>>>>>> Let's make a firm plan for getting your work committed and running in
>>>>>> production. We may need to cut scope from your milestone 2 objectives in
>>>>>> order to meet this goal, but that's just fine -- this is how software gets
>>>>>> built in industry.
>>>>>>
>>>>>> So, what will you need to get a PR merged into Phoenix? From looking
>>>>>> through your branch, the following are the top objectives. We can dive into
>>>>>> them one-by-one.
>>>>>>
>>>>>> * 1. Work from a fork of Phoenix, not your own project.*
>>>>>>
>>>>>> This may require you learning some more git; I don't know your skill
>>>>>> level with this tool. It also will interrupt your development workflow for
>>>>>> a little while as you become comfortable working with Phoenix from source
>>>>>> instead of the 4.4.0 release artifact.
>>>>>>
>>>>>> * 2. Web service that is launched with a python script from bin.*
>>>>>>
>>>>>> We're going to need to create a new module in the Phoenix build for
>>>>>> your jetty service, that way it's built as part of Phoenix. We'll also need
>>>>>> to add a launch script to Phoenix's bin directory because mvn run is not
>>>>>> acceptable production deployments.
>>>>>>
>>>>>> * 3. The tracing tools queries the real tracing table for spans.*
>>>>>>
>>>>>> There's no reason to merge a tool that's querying over sample data.
>>>>>> You have the jetty service for hosting the JavaScript application, so you
>>>>>> already have a place for Java code that interacts with Phoenix. You're
>>>>>> going to need a span query API to communicate from JavaScript to Java; you
>>>>>> already have the bones of this API in the mocked span data structures you
>>>>>> use for your demos.
>>>>>>
>>>>>> * 4. The UI renders those spans.*
>>>>>>
>>>>>> This part's easy; you already have good progress on the UI. I
>>>>>> explicitly mention it because it's a requirement for committable code and
>>>>>> there's always new bugs when integrating systems. Expect to make some
>>>>>> tweaks here once you get some real behind the queries.
>>>>>>
>>>>>> This is a lot of work, some of it you may not be comfortable with,
>>>>>> but I think you can do it. The community is here to help you -- I'm here to
>>>>>> help you.
>>>>>>
>>>>>> Getting your JavaScript app wired up and showing real tracing table
>>>>>> data is the MOST IMPORTANT thing right now. Once you have that, we can
>>>>>> start improving it with displaying user's SQL instead of trace IDs and so
>>>>>> on. I highly recommend you focus on 1-4 above; we'll resume milestone 2
>>>>>> objectives once your initial work is committed.
>>>>>>
>>>>>> As always, I'm available by email, Skype, IM, G+; whatever is
>>>>>> convenient for you. Let's get your work out there, committed and into
>>>>>> production so that Phoenix users have access to this new, powerful tool
>>>>>> you're building! Let's also get your name into the Phoenix commit history :)
>>>>>>
>>>>>> -n
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards,
>>>> Nishani Jayamaha
>>>> http://ayolajayamaha.blogspot.com/
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Best Regards,
>> Nishani Jayamaha
>> http://ayolajayamaha.blogspot.com/
>>
>>
>>
>
>
> --
> Best Regards,
> Nishani Jayamaha
> http://ayolajayamaha.blogspot.com/
>
>
>
--
Best Regards,
Nishani Jayamaha
http://ayolajayamaha.blogspot.com/
Re: Working toward merge requests and commits to Phoenix
Posted by Ayola Jayamaha <ra...@gmail.com>.
Hi Nick,
Thanks for the comments. I rectified some of the issues and left answered
the questions. The rest of the issues I will tackle and keep on updating on
the PR[1] and my blog[2].
Thanks.
[1] https://github.com/apache/phoenix/pull/96
[2] http://ayolajayamaha.blogspot.com/
On Sat, Jul 4, 2015 at 12:11 AM, Nick Dimiduk <nd...@apache.org> wrote:
> I left some comments on your PR; this one is much more usable than PR 95.
>
> On Fri, Jul 3, 2015 at 11:06 AM, Ayola Jayamaha <ra...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I am working on milestone3 PR[1]. I have updated the pom mapping to the
>> Phoenix parent pom. I will write the launching script in Phoenix bin. I'm
>> progressing on making the web app standalone. As I'm progressing through
>> the task list I will tick them.
>>
>> Let me know if I missed anything on the task list.
>> Thanks.
>>
>> [1] https://github.com/apache/phoenix/pull/96
>>
>> On Fri, Jul 3, 2015 at 8:41 AM, Ayola Jayamaha <ra...@gmail.com>
>> wrote:
>>
>> > Hi Nick,
>> >
>> > I have created a pull request [1]. After going through the steps that
>> you
>> > have given and the resources I was able to create it with no conflicts
>> and
>> > it is giving a green button. So I think it is fine. If there is some
>> > mistake please let me know.
>> > Step 1 has been done. Updating the pom files are yet to be done.
>> >
>> > Thanks.
>> >
>> > [1] https://github.com/apache/phoenix/pull/96
>> >
>> > On Fri, Jul 3, 2015 at 12:46 AM, Ayola Jayamaha <raphaelanne2@gmail.com
>> >
>> > wrote:
>> >
>> >> Thanks James and Nick for Quick reply.
>> >>
>> >> On Fri, Jul 3, 2015 at 12:05 AM, Nick Dimiduk <nd...@apache.org>
>> >> wrote:
>> >>
>> >>> * 1. Work from a fork of Phoenix, not your own project.*
>> >>>> Yes I know the git work flow some far. And I can get a fork from
>> >>>> Phoenix and do my implementation there(branch).
>> >>>>
>> >>>
>> >>> Great!
>> >>>
>> >>> I have created the milestone 3 branch(Phoenix 4.4 Hbase 9.8) and I
>> have
>> >>>> sent the pull request and it is not completed (pom file is not
>> pointing to
>> >>>> the Phoenix parent pom still). If I have done any mistake please let
>> me
>> >>>> know.
>> >>>>
>> >>>> [1] https://github.com/apache/phoenix/pull/95
>> >>>>
>> >>>
>> >>> Yikes, this needs some git-hygeine. Your PR should contain only your
>> >>> changes. Please rebase your changes on top of the existing branch.
>> >>> Something like the following commands should suffice (assuming you
>> have
>> >>> github.com/apache/phoenix as origin):
>> >>>
>> >>> $ git remote update
>> >>> $ git checkout nishanis-branch
>> >>> $ git rebase origin/4.4-HBase-0.98
>> >>>
>> >>> I will try to follow them. and try to fix it
>> >>
>> >> That should give you just your commits at the HEAD, and you can base
>> your
>> >>> PR from that. We can walk through this with a screen share if you'd
>> like, I
>> >>> have time today and tomorrow.
>> >>>
>> >> Thanks, If I was not able. I will share screen and get the help
>> tomorrow
>> >>
>> >>
>> >>> There's a pretty good description of rebase:
>> >>> http://www.git-tower.com/blog/understanding-rebase-merge-in-git/
>> >>>
>> >>> * 2. Web service that is launched with a python script from bin.*
>> >>>> I will add a new folder in root level of Phoenix(4.4.0 9.8Hbase)
>> called
>> >>>> (tracingwebapp). And when you run the build from root level(need to
>> update
>> >>>> the root pom of Phoenix) or build from the folder level
>> tracingwebapp and
>> >>>> it will build the war file. So I will add a launching script to the
>> bin of
>> >>>> Phoenix to start the war file. Is it fine?
>> >>>>
>> >>>
>> >>> We'll need it integrated into Phoenix's build, so that `mvn clean
>> >>> package` from the Phoenix root will also build your code and run your
>> >>> tests. Phoenix is a "multi-module" project, which means it consists of
>> >>> multiple independent components. We're going to add tracingwebapp as
>> a new
>> >>> component. You can see how the pom.xml file in the root of the project
>> >>> defines a list of modules. tracingwebapp will be added to that list.
>> >>>
>> >> Think looking on the other pom file in Phoenix. I can make it.
>> >>
>> >>>
>> >>> There's a text-book example of multi-module projects:
>> >>> http://books.sonatype.com/mvnex-book/reference/multimodule.html
>> >>>
>> >>> * 3. The tracing tools queries the real tracing table for spans.*
>> >>>> I have written a Java code to to read the tracing data of Phoenix and
>> >>>> adding it to a text file. It is not added to Jetty yet. I would be
>> needing
>> >>>> help to communicate from Java to Javascript.
>> >>>>
>> >>>
>> >>> Excellent! We can start working on that once you have steps (1) and
>> (2)
>> >>> pulled together.
>> >>>
>> >>> * 4. The UI renders those spans.*
>>
>> >>>> Yes there will be issues when integrating. At the moment I have sent
>> a
>> >>>> PR. I'm not sure I did it correctly.
>> >>>>
>> >>>
>> >>> I'm not sure which PR you mean, do you have a link?
>> >>>
>> >> That I have shared in above
>> >> [1] https://github.com/apache/phoenix/pull/95
>> >>
>> >> steps that I followed
>> >> 1. Got the fork from Apache
>> >> 2. Make a new branch ' milestone 3' [2] on 4.4-HBase-0.98
>> >>
>> >> [2] https://github.com/AyolaJayamaha/phoenix/tree/milestone-3
>> >>
>> >>
>> >>
>> >>>
>> >>> After the mid-term communicate from Java to Javascript will be the
>> first
>> >>>> part. These changes will be done on the PR.
>> >>>>
>> >>>
>> >>> During development, it's better to work from a personal branch (which
>> >>> can be public on your own public github repository) instead of PR's.
>> We can
>> >>> collaborate there -- you can push commits to it, we can comment on
>> them,
>> >>> you can push fixes, squishing history and so on. Once your branch is
>> in
>> >>> good shape, you rebase it onto the latest community changes and then
>> >>> publish your PR. We can practice this workflow after you've completed
>> (1)
>> >>> anove.
>> >>>
>> >> ok
>> >>
>> >>>
>> >>> On Wed, Jul 1, 2015 at 10:28 PM, James Taylor <jamestaylor@apache.org
>> >
>> >>>> wrote:
>> >>>>
>> >>>>> I second what Nick said - we need to be driving the UI directly from
>> >>>>> Phoenix queries against the trace table. I think with #3, one
>> valuable
>> >>>>> output will be a series of Phoenix queries that provide insight into
>> >>>>> understanding the performance of a query.
>> >>>>>
>> >>>>> Unfortunately, what you've done so far isn't helping Phoenix. This
>> >>>>> needs to be fixed quickly, or we've failed in my mind.
>> >>>>>
>> >>>>> Are you working full-time on this, Nishani?
>> >>>>>
>> >>>>> Thanks,
>> >>>>> James
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Tue, Jun 30, 2015 at 12:16 PM, Nick Dimiduk <ndimiduk@apache.org
>> >
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Hi Nishani,
>> >>>>>>
>> >>>>>> I'm glad to see your self-modivation and continued progress. UI
>> >>>>>> development is not my strength, and I like how you've interacted
>> with the
>> >>>>>> community to solicit feedback through your prototyping stages. One
>> thing we
>> >>>>>> are concerned about is your project coming to a point where it's
>> ready to
>> >>>>>> be committed back to Phoenix. I think it would be a real shame for
>> you and
>> >>>>>> for Apache if your work is not merged into the project.
>> >>>>>>
>> >>>>>> Let's make a firm plan for getting your work committed and running
>> in
>> >>>>>> production. We may need to cut scope from your milestone 2
>> objectives in
>> >>>>>> order to meet this goal, but that's just fine -- this is how
>> software gets
>> >>>>>> built in industry.
>> >>>>>>
>> >>>>>> So, what will you need to get a PR merged into Phoenix? From
>> looking
>> >>>>>> through your branch, the following are the top objectives. We can
>> dive into
>> >>>>>> them one-by-one.
>> >>>>>>
>> >>>>>> * 1. Work from a fork of Phoenix, not your own project.*
>> >>>>>>
>> >>>>>> This may require you learning some more git; I don't know your
>> skill
>> >>>>>> level with this tool. It also will interrupt your development
>> workflow for
>> >>>>>> a little while as you become comfortable working with Phoenix from
>> source
>> >>>>>> instead of the 4.4.0 release artifact.
>> >>>>>>
>> >>>>>> * 2. Web service that is launched with a python script from bin.*
>> >>>>>>
>> >>>>>> We're going to need to create a new module in the Phoenix build for
>> >>>>>> your jetty service, that way it's built as part of Phoenix. We'll
>> also need
>> >>>>>> to add a launch script to Phoenix's bin directory because mvn run
>> is not
>> >>>>>> acceptable production deployments.
>> >>>>>>
>> >>>>>> * 3. The tracing tools queries the real tracing table for spans.*
>> >>>>>>
>> >>>>>> There's no reason to merge a tool that's querying over sample data.
>> >>>>>> You have the jetty service for hosting the JavaScript application,
>> so you
>> >>>>>> already have a place for Java code that interacts with Phoenix.
>> You're
>> >>>>>> going to need a span query API to communicate from JavaScript to
>> Java; you
>> >>>>>> already have the bones of this API in the mocked span data
>> structures you
>> >>>>>> use for your demos.
>> >>>>>>
>> >>>>>> * 4. The UI renders those spans.*
>>
>> >>>>>>
>> >>>>>> This part's easy; you already have good progress on the UI. I
>> >>>>>> explicitly mention it because it's a requirement for committable
>> code and
>> >>>>>> there's always new bugs when integrating systems. Expect to make
>> some
>> >>>>>> tweaks here once you get some real behind the queries.
>> >>>>>>
>> >>>>>> This is a lot of work, some of it you may not be comfortable with,
>> >>>>>> but I think you can do it. The community is here to help you --
>> I'm here to
>> >>>>>> help you.
>> >>>>>>
>> >>>>>> Getting your JavaScript app wired up and showing real tracing table
>> >>>>>> data is the MOST IMPORTANT thing right now. Once you have that, we
>> can
>> >>>>>> start improving it with displaying user's SQL instead of trace IDs
>> and so
>> >>>>>> on. I highly recommend you focus on 1-4 above; we'll resume
>> milestone 2
>> >>>>>> objectives once your initial work is committed.
>> >>>>>>
>> >>>>>> As always, I'm available by email, Skype, IM, G+; whatever is
>> >>>>>> convenient for you. Let's get your work out there, committed and
>> into
>> >>>>>> production so that Phoenix users have access to this new, powerful
>> tool
>> >>>>>> you're building! Let's also get your name into the Phoenix commit
>> history :)
>> >>>>>>
>> >>>>>> -n
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Best Regards,
>> >>>> Nishani Jayamaha
>> >>>> http://ayolajayamaha.blogspot.com/
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Best Regards,
>> >> Nishani Jayamaha
>> >> http://ayolajayamaha.blogspot.com/
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > Best Regards,
>> > Nishani Jayamaha
>> > http://ayolajayamaha.blogspot.com/
>> >
>> >
>> >
>>
>>
>> --
>> Best Regards,
>> Nishani Jayamaha
>> http://ayolajayamaha.blogspot.com/
>>
>
>
--
Best Regards,
Nishani Jayamaha
http://ayolajayamaha.blogspot.com/
Re: Working toward merge requests and commits to Phoenix
Posted by Nick Dimiduk <nd...@apache.org>.
I left some comments on your PR; this one is much more usable than PR 95.
On Fri, Jul 3, 2015 at 11:06 AM, Ayola Jayamaha <ra...@gmail.com>
wrote:
> Hi,
>
> I am working on milestone3 PR[1]. I have updated the pom mapping to the
> Phoenix parent pom. I will write the launching script in Phoenix bin. I'm
> progressing on making the web app standalone. As I'm progressing through
> the task list I will tick them.
>
> Let me know if I missed anything on the task list.
> Thanks.
>
> [1] https://github.com/apache/phoenix/pull/96
>
> On Fri, Jul 3, 2015 at 8:41 AM, Ayola Jayamaha <ra...@gmail.com>
> wrote:
>
> > Hi Nick,
> >
> > I have created a pull request [1]. After going through the steps that you
> > have given and the resources I was able to create it with no conflicts
> and
> > it is giving a green button. So I think it is fine. If there is some
> > mistake please let me know.
> > Step 1 has been done. Updating the pom files are yet to be done.
> >
> > Thanks.
> >
> > [1] https://github.com/apache/phoenix/pull/96
> >
> > On Fri, Jul 3, 2015 at 12:46 AM, Ayola Jayamaha <ra...@gmail.com>
> > wrote:
> >
> >> Thanks James and Nick for Quick reply.
> >>
> >> On Fri, Jul 3, 2015 at 12:05 AM, Nick Dimiduk <nd...@apache.org>
> >> wrote:
> >>
> >>> * 1. Work from a fork of Phoenix, not your own project.*
> >>>> Yes I know the git work flow some far. And I can get a fork from
> >>>> Phoenix and do my implementation there(branch).
> >>>>
> >>>
> >>> Great!
> >>>
> >>> I have created the milestone 3 branch(Phoenix 4.4 Hbase 9.8) and I have
> >>>> sent the pull request and it is not completed (pom file is not
> pointing to
> >>>> the Phoenix parent pom still). If I have done any mistake please let
> me
> >>>> know.
> >>>>
> >>>> [1] https://github.com/apache/phoenix/pull/95
> >>>>
> >>>
> >>> Yikes, this needs some git-hygeine. Your PR should contain only your
> >>> changes. Please rebase your changes on top of the existing branch.
> >>> Something like the following commands should suffice (assuming you have
> >>> github.com/apache/phoenix as origin):
> >>>
> >>> $ git remote update
> >>> $ git checkout nishanis-branch
> >>> $ git rebase origin/4.4-HBase-0.98
> >>>
> >>> I will try to follow them. and try to fix it
> >>
> >> That should give you just your commits at the HEAD, and you can base
> your
> >>> PR from that. We can walk through this with a screen share if you'd
> like, I
> >>> have time today and tomorrow.
> >>>
> >> Thanks, If I was not able. I will share screen and get the help
> tomorrow
> >>
> >>
> >>> There's a pretty good description of rebase:
> >>> http://www.git-tower.com/blog/understanding-rebase-merge-in-git/
> >>>
> >>> * 2. Web service that is launched with a python script from bin.*
> >>>> I will add a new folder in root level of Phoenix(4.4.0 9.8Hbase)
> called
> >>>> (tracingwebapp). And when you run the build from root level(need to
> update
> >>>> the root pom of Phoenix) or build from the folder level tracingwebapp
> and
> >>>> it will build the war file. So I will add a launching script to the
> bin of
> >>>> Phoenix to start the war file. Is it fine?
> >>>>
> >>>
> >>> We'll need it integrated into Phoenix's build, so that `mvn clean
> >>> package` from the Phoenix root will also build your code and run your
> >>> tests. Phoenix is a "multi-module" project, which means it consists of
> >>> multiple independent components. We're going to add tracingwebapp as a
> new
> >>> component. You can see how the pom.xml file in the root of the project
> >>> defines a list of modules. tracingwebapp will be added to that list.
> >>>
> >> Think looking on the other pom file in Phoenix. I can make it.
> >>
> >>>
> >>> There's a text-book example of multi-module projects:
> >>> http://books.sonatype.com/mvnex-book/reference/multimodule.html
> >>>
> >>> * 3. The tracing tools queries the real tracing table for spans.*
> >>>> I have written a Java code to to read the tracing data of Phoenix and
> >>>> adding it to a text file. It is not added to Jetty yet. I would be
> needing
> >>>> help to communicate from Java to Javascript.
> >>>>
> >>>
> >>> Excellent! We can start working on that once you have steps (1) and (2)
> >>> pulled together.
> >>>
> >>> * 4. The UI renders those spans.*
> >>>> Yes there will be issues when integrating. At the moment I have sent a
> >>>> PR. I'm not sure I did it correctly.
> >>>>
> >>>
> >>> I'm not sure which PR you mean, do you have a link?
> >>>
> >> That I have shared in above
> >> [1] https://github.com/apache/phoenix/pull/95
> >>
> >> steps that I followed
> >> 1. Got the fork from Apache
> >> 2. Make a new branch ' milestone 3' [2] on 4.4-HBase-0.98
> >>
> >> [2] https://github.com/AyolaJayamaha/phoenix/tree/milestone-3
> >>
> >>
> >>
> >>>
> >>> After the mid-term communicate from Java to Javascript will be the
> first
> >>>> part. These changes will be done on the PR.
> >>>>
> >>>
> >>> During development, it's better to work from a personal branch (which
> >>> can be public on your own public github repository) instead of PR's.
> We can
> >>> collaborate there -- you can push commits to it, we can comment on
> them,
> >>> you can push fixes, squishing history and so on. Once your branch is in
> >>> good shape, you rebase it onto the latest community changes and then
> >>> publish your PR. We can practice this workflow after you've completed
> (1)
> >>> anove.
> >>>
> >> ok
> >>
> >>>
> >>> On Wed, Jul 1, 2015 at 10:28 PM, James Taylor <ja...@apache.org>
> >>>> wrote:
> >>>>
> >>>>> I second what Nick said - we need to be driving the UI directly from
> >>>>> Phoenix queries against the trace table. I think with #3, one
> valuable
> >>>>> output will be a series of Phoenix queries that provide insight into
> >>>>> understanding the performance of a query.
> >>>>>
> >>>>> Unfortunately, what you've done so far isn't helping Phoenix. This
> >>>>> needs to be fixed quickly, or we've failed in my mind.
> >>>>>
> >>>>> Are you working full-time on this, Nishani?
> >>>>>
> >>>>> Thanks,
> >>>>> James
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Jun 30, 2015 at 12:16 PM, Nick Dimiduk <nd...@apache.org>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi Nishani,
> >>>>>>
> >>>>>> I'm glad to see your self-modivation and continued progress. UI
> >>>>>> development is not my strength, and I like how you've interacted
> with the
> >>>>>> community to solicit feedback through your prototyping stages. One
> thing we
> >>>>>> are concerned about is your project coming to a point where it's
> ready to
> >>>>>> be committed back to Phoenix. I think it would be a real shame for
> you and
> >>>>>> for Apache if your work is not merged into the project.
> >>>>>>
> >>>>>> Let's make a firm plan for getting your work committed and running
> in
> >>>>>> production. We may need to cut scope from your milestone 2
> objectives in
> >>>>>> order to meet this goal, but that's just fine -- this is how
> software gets
> >>>>>> built in industry.
> >>>>>>
> >>>>>> So, what will you need to get a PR merged into Phoenix? From looking
> >>>>>> through your branch, the following are the top objectives. We can
> dive into
> >>>>>> them one-by-one.
> >>>>>>
> >>>>>> * 1. Work from a fork of Phoenix, not your own project.*
> >>>>>>
> >>>>>> This may require you learning some more git; I don't know your skill
> >>>>>> level with this tool. It also will interrupt your development
> workflow for
> >>>>>> a little while as you become comfortable working with Phoenix from
> source
> >>>>>> instead of the 4.4.0 release artifact.
> >>>>>>
> >>>>>> * 2. Web service that is launched with a python script from bin.*
> >>>>>>
> >>>>>> We're going to need to create a new module in the Phoenix build for
> >>>>>> your jetty service, that way it's built as part of Phoenix. We'll
> also need
> >>>>>> to add a launch script to Phoenix's bin directory because mvn run
> is not
> >>>>>> acceptable production deployments.
> >>>>>>
> >>>>>> * 3. The tracing tools queries the real tracing table for spans.*
> >>>>>>
> >>>>>> There's no reason to merge a tool that's querying over sample data.
> >>>>>> You have the jetty service for hosting the JavaScript application,
> so you
> >>>>>> already have a place for Java code that interacts with Phoenix.
> You're
> >>>>>> going to need a span query API to communicate from JavaScript to
> Java; you
> >>>>>> already have the bones of this API in the mocked span data
> structures you
> >>>>>> use for your demos.
> >>>>>>
> >>>>>> * 4. The UI renders those spans.*
> >>>>>>
> >>>>>> This part's easy; you already have good progress on the UI. I
> >>>>>> explicitly mention it because it's a requirement for committable
> code and
> >>>>>> there's always new bugs when integrating systems. Expect to make
> some
> >>>>>> tweaks here once you get some real behind the queries.
> >>>>>>
> >>>>>> This is a lot of work, some of it you may not be comfortable with,
> >>>>>> but I think you can do it. The community is here to help you -- I'm
> here to
> >>>>>> help you.
> >>>>>>
> >>>>>> Getting your JavaScript app wired up and showing real tracing table
> >>>>>> data is the MOST IMPORTANT thing right now. Once you have that, we
> can
> >>>>>> start improving it with displaying user's SQL instead of trace IDs
> and so
> >>>>>> on. I highly recommend you focus on 1-4 above; we'll resume
> milestone 2
> >>>>>> objectives once your initial work is committed.
> >>>>>>
> >>>>>> As always, I'm available by email, Skype, IM, G+; whatever is
> >>>>>> convenient for you. Let's get your work out there, committed and
> into
> >>>>>> production so that Phoenix users have access to this new, powerful
> tool
> >>>>>> you're building! Let's also get your name into the Phoenix commit
> history :)
> >>>>>>
> >>>>>> -n
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best Regards,
> >>>> Nishani Jayamaha
> >>>> http://ayolajayamaha.blogspot.com/
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >> --
> >> Best Regards,
> >> Nishani Jayamaha
> >> http://ayolajayamaha.blogspot.com/
> >>
> >>
> >>
> >
> >
> > --
> > Best Regards,
> > Nishani Jayamaha
> > http://ayolajayamaha.blogspot.com/
> >
> >
> >
>
>
> --
> Best Regards,
> Nishani Jayamaha
> http://ayolajayamaha.blogspot.com/
>