Store vendor code or not

[YujiOshima]

Including vendor code in this repo makes difficult to review.
#142 (comment)
#141 (comment)

https://github.com/golang/dep/blob/master/docs/FAQ.md#should-i-commit-my-vendor-directory

• Pros

It's the only way to get truly reproducible builds, as it guards against upstream renames, deletes and commit history overwrites.
You don't need an extra dep ensure step to sync vendor/ with Gopkg.lock after most operations, such as go get, cloning, getting latest, merging, etc.

• Cons

Your repo will be bigger, potentially a lot bigger, though prune can help minimize this problem.
PR diffs will include changes for files under vendor/ when Gopkg.lock is modified, however files in vendor/ are hidden by default on GitHub.
We can protect it from deletion of depending repository by including vendor folders.

I think the more Katib mature, the less vendored folders change.

WDYT
@jlewi @vinaykakade @gaocegege

[jlewi]

Including vendor is making it really difficult to review the PRs. I'd be in favor of removing vendor at least for now just for that reason.

[vinaykakade]

I am supportive of removing the vendor code from Katib. Agree that it is much easier to review the PRs without vendor folder.

[gaocegege]

I think if we use dep, and we definitely can remove vendor from git.

[YujiOshima]

@jlewi @vinaykakade @gaocegege Thanks.
I will remove vendor code from Katib repo.
We will only maintain only Gopkg.lock and Gopkg.toml.