Document the development environment setup

[shtripat]

Document the development environment setup

[sankarshanmukhopadhyay]

ACK. @r0h4n will work with @GowthamShanmugam and you to set up the conversation. If you can create a documentation PR once you are set up, we should be closing the loop on this.

[GowthamShanmugam]

After discussion I will document it sir,

Thanks & regards
Gowtham S
----- Original Message -----
From: "sankarshan" [email protected]
To: "Tendrl/documentation" [email protected]
Cc: "Gowtham Shanmugasundaram" [email protected], "Mention" [email protected]
Sent: Tuesday, September 20, 2016 7:36:29 PM
Subject: Re: [Tendrl/documentation] Document the development environment setup (#17)

ACK. @r0h4n will work with @GowthamShanmugam and you to set up the conversation. If you can create a documentation PR once you are set up, we should be closing the loop on this.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#17 (comment)

[GowthamShanmugam]

Tendrl – Configuring Development Environment

Github Issue:
It is nothing but a bug report. Whenever a new issue/bug raises, We can document the bug with title and detailed bug description in github. Each repository have its individual bug reporting page. So we can document the bug in which repository it is related to. These are the bug reporting pages, It will show list of bugs related to Tendrl project.

    - Bridge_common  : https://github.com/Tendrl/bridge_common/issues
    - Ceph_bridge        : https://github.com/Tendrl/ceph_bridge/issues
    - Gluster_bridge    : https://github.com/Tendrl/gluster_bridge/issues

How to raise a new issue/bug on github ?
In issues page press an option → New issue → In Title : give any title related to that issue/bug → In Comment : gieve detailed description about the issue/bug → press Submit new issue. (Note: github also provides some labels for more attractive comments also).

Cloning Repository:
Before clone a particular repository we have to fork it out using our individual github account. For that press an option called Fork , Now you can see the copied repository in your personal repository list.

What is fork?
A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project. It just copy a actual repository as your personal repository.
Now your repository is ready to clone. You can clone the repository using two options one is clone with SSH and another one is HTTPS. If you are cloning the particular repository using HTTPS, Then you have to give username and password each and every time of giving push request. If you are clone using SSH then you have to configure your machine SSH public key with github.

How to configure public SSH key with github ?
In your local machine type command ssh-keygen to generate your machine SSH public key. Inside /root/.ssh/id_rsa.pub you can copy the actual machine SSH public key. To configure SSH key with github, In github page press option called view your profile and more→ settings → SSH and GPG keys → New SSH key → pate the copied SSH public key inside the box and give some related title for that → Add SSH key. Now your machine is configured SSH key with github.
After that you have to clone the copied repository to your local machine. For that press option called Clone or download top right hand side of the page. Choose option either clone use HTTPS or SSH. In local machine clone the repository using command git clone.

Using SSH :

    - Bridge_common : [email protected]:Tendrl/bridge_common.git
    - Ceph_bridge      : [email protected]:Tendrl/ceph_bridge.git
    - Gluster_bridge   : [email protected]:Tendrl/gluster_bridge.git

Using HTTPS:

    - Bridge_common : https://github.com/Tendrl/bridge_common.git
    - Ceph_bridge      : https://github.com/Tendrl/ceph_bridge.git
    - Gluster_bridge   : https://github.com/Tendrl/gluster_bridge.git

(For example: git clone [email protected]:Tendrl/bridge_common.git)

Creating Pull Request:
After git clone all the repositories are copied into your local machine. Now you can do your own changes in your local machine repositories. Before that Create a new branch and do your modifications inside that newly created branch (use git checkout -b branch name). After made all the changes you have to commit and push your patch (nothing but changes of your own) to remote repository (forked personal repository not an original repository).
Before run and test your modification you have to install some dependency software.

Dependent software's to test and run your changes:

    1. Python 2.7 (Already installed in fedora) (For development)
    2. Tox (pip install tox) (For test your project)
    3. pep8 (yum install python-pep8) (For check indentation)    

(Note: After modification you can run your code using command bash run_travis.sh)

Steps to commit and send patch to remote:

    1. Use git status to check current state of repository, Which will show all modified file.
    2. Choose what are the file you want to send to remote repository using git add.
    3. Commit your changes using git commit -s.
    4. type command git log to verify your patch is in top or not.
    5. Push your patch using git push origin command.

Now you can see the branch count is increased in github page. Press option branch and you can see all modification which is sent from your local machine to github page.Before create pull request you just compare your change with master once, For that press option compare and pull request in github page. By pressing pull request pull request option you create a new pull request.

Verifying Pull Request :
After giving pull request you have to check certain things are passed correctly.

    1. Check whether branch have any conflict with base branch or not, if any conflict then remove the conflict from your code and resend it again.
    2. Check travis ci build is passed or not : travis ci build will pass only there no any indentation error and import errors. If both are pass then it will show green at the end of the page.

(Note: Travis CI uses pep8 and cover command to check the build)

Reviewing Code :
For reviewing a code github provide a tool called Review Ninja. You can use your github account to login into review ninja. After login you can view and review others code easily.

Note: This document explains how to configure a basic development environment and github work flow, Due to time constraints a full fledged document will be updated later.

@r0h4n , @sankarshanmukhopadhyay , @nthomas-redhat , @nnDarshan , @anmolbabu , @karnan4ever

[sankarshanmukhopadhyay]

It seems to me that we are talking about 2 different things. The topic which @shtripat had pointed out was to have a document which would enable a new developer to the project set up their environment in a manner which gets them along. This might include things like (a) editors (b) host OS and virtual machine instances with specific OS versions (c) development libraries (d) virtual environment and such

This would also provide a simple at-a-glance method to ensure that OS versions and such are all kept synchronized or, at least, the target environments are not dissimilar.

[GowthamShanmugam]

@sankarshanmukhopadhyay , In first session because of time constrains @r0h4n explained this much of details only. Still those type of details are not discussed briefly. That why i commented like this document contains only basic development development environment configuration details. @r0h4n we have to discuss more about this.

[karnan4ever]

@GowthamShanmugam, this document is more related repo and git.
As pointed out by @sankarshanmukhopadhyay, Can you add more information about the tools , supported OS, dev dependancy libraries. I can use it to document something like Setting-up-your-Development-Environment

On top of that, adding steps about making local build and testing would be very useful.

[GowthamShanmugam]

@karnan4ever , I will add it