phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ayola Jayamaha <raphaelan...@gmail.com>
Subject Re: Working toward merge requests and commits to Phoenix
Date Fri, 03 Jul 2015 18:06:52 GMT
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 <raphaelanne2@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 <ndimiduk@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/

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