MyFavMirrors
/
minio
mirror of https://github.com/minio/minio.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
minio/CONTRIBUTING.md

71 lines
2.7 KiB
Markdown
Raw Normal View History

Update CONTRIBUTING.md
2015-05-27 21:41:14 -04:00
### Install Golang
If you do not have a working Golang environment setup please follow [Golang Installation Guide](./INSTALLGO.md).
A full restructure
2014-12-29 19:35:56 -05:00
### Setup your Minio Github Repository
More scripts and code from Minio-io to minio
2015-05-11 19:43:38 -04:00
Fork [Minio upstream](https://github.com/minio/minio/fork) source repository to your own personal repository. Copy the URL and pass it to ``go get`` command. Go uses git to clone a copy into your project workspace folder.
A full restructure
2014-12-29 19:35:56 -05:00
```sh
Change all minio-io path to minio
2015-05-11 19:23:10 -04:00
$ mkdir -p $GOPATH/src/github.com/minio
$ cd $GOPATH/src/github.com/minio
A full restructure
2014-12-29 19:35:56 -05:00
$ git clone https://github.com/$USER_ID/minio
$ cd minio
```
### Compiling Minio from source
Consolidate developers docs and Makefile, create symlink automatically
2015-02-02 00:18:46 -05:00
Minio uses ``Makefile`` to wrap around some of the limitations of ``go`` build system. To compile Minio source, simply change to your workspace folder and type ``make``.
A full restructure
2014-12-29 19:35:56 -05:00
```sh
$ make
Checking if proper environment variables are set.. Done
...
Checking dependencies for Minio.. Done
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
Installed govet
Consolidate developers docs and Makefile, create symlink automatically
2015-02-02 00:18:46 -05:00
Building Libraries
A full restructure
2014-12-29 19:35:56 -05:00
...
...
```
Consolidate developers docs and Makefile, create symlink automatically
2015-02-02 00:18:46 -05:00
No symlink, fail when not in GOPATH
2015-02-18 17:35:49 -05:00
### Setting up git remote as ``upstream``
```sh
Change all minio-io path to minio
2015-05-11 19:23:10 -04:00
$ cd $GOPATH/src/github.com/minio/minio
$ git remote add upstream https://github.com/minio/minio
No symlink, fail when not in GOPATH
2015-02-18 17:35:49 -05:00
$ git fetch upstream
$ git merge upstream/master
...
...
$ make
Checking if proper environment variables are set.. Done
...
Checking dependencies for Minio.. Done
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
Installed govet
No symlink, fail when not in GOPATH
2015-02-18 17:35:49 -05:00
Building Libraries
...
```
A full restructure
2014-12-29 19:35:56 -05:00
### Developer Guidelines
Update DEVELOPER.md
2014-12-30 20:45:17 -05:00
``Minio`` community welcomes your contribution. To make the process as seamless as possible, we ask for the following:
A full restructure
2014-12-29 19:35:56 -05:00
* Go ahead and fork the project and make your changes. We encourage pull requests to discuss code changes.
Update contributors document
2015-02-09 16:34:19 -05:00
- Fork it
- Create your feature branch (git checkout -b my-new-feature)
- Commit your changes (git commit -am 'Add some feature')
- Push to the branch (git push origin my-new-feature)
- Create new Pull Request
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
* If you have additional dependencies for ``Minio``, ``Minio`` manages its depedencies using [govendor](https://github.com/kardianos/govendor)
Update contributors document
2015-02-09 16:34:19 -05:00
- Run `go get foo/bar`
- Edit your code to import foo/bar
Add package add and remove commands to Makefile
2015-08-23 01:23:36 -04:00
- Run `make pkg-add PKG=foo/bar` from top-level directory
* If you have dependencies for ``Minio`` which needs to be removed
- Edit your code to not import foo/bar
- Run `make pkg-remove PKG=foo/bar` from top-level directory
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
A full restructure
2014-12-29 19:35:56 -05:00
* When you're ready to create a pull request, be sure to:
Update contributors document
2015-02-09 16:34:19 -05:00
- Have test cases for the new code. If you have questions about how to do it, please ask in your pull request.
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
- Run `make verifiers`
Update contributors document
2015-02-09 16:34:19 -05:00
- Squash your commits into a single commit. `git rebase -i`. It's okay to force update your pull request.
- Make sure `go test -race ./...` and `go build` completes.
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
Update DEVELOPER.md
2014-12-30 20:45:17 -05:00
* Read [Effective Go](https://github.com/golang/go/wiki/CodeReviewComments) article from Golang project
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
- `Minio` project is fully conformant with Golang style
Update contributors document
2015-02-09 16:34:19 -05:00
- if you happen to observe offending code, please feel free to send a pull request