Hi Willem, OK I got your point. I just checked the Serive-Center's dependencies. It seems that all the third-parties it depends on are on Category A list(the go dependencies and JS dependencies). So we can include the vendor in the source release archive. We will need to update the LICENSE/NOTICE for source release.
If someday we added a Category B licensed dependency then we cannot include it in the source release. Luckily those licenses(EPL,MPL,CC-A,CCDL) are rare on the go ecosystem. On Mon, Aug 27, 2018 at 11:48 AM Willem Jiang <[email protected]> wrote: > I'm not object to put the third party code into git repository. > My point is if we want to help the user build the kit from source easily, > we should not delete the vendor directory when doing the source release. > For the k8s source release[1], it still includes the vendor directory. > > [1]https://dl.k8s.io/v1.11.0/kubernetes-src.tar.gz > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > > On Mon, Aug 27, 2018 at 11:27 AM Yang Bo <[email protected]> wrote: > > > It's pretty common for go projects to include the vendor directory in > their > > repository. > > https://github.com/kubernetes/kubernetes/tree/master/vendor > > > > And it's common knowledge that the code under vendor directory is from > > third-parties in the go ecosystem. So it seems natural that the > repository > > provide the vendor directory for convenience but the source release does > > not. The user can still build from source following the instructions in > the > > README. > > > > On Mon, Aug 27, 2018 at 7:52 AM Willem Jiang <[email protected]> > > wrote: > > > > > Apache provides the source release for the user who want to build the > kit > > > from scratch. > > > If there are too much difference between the source release kit and > that > > he > > > get from the git repo with the tag, we need to explain it. > > > Normally community user only want to use the release version of the > kit, > > if > > > we exclude the vendor source in the release kit, why do we need to put > > them > > > into the git repo? > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > > > > On Sat, Aug 25, 2018 at 5:52 PM Yang Bo <[email protected]> wrote: > > > > > > > +1 > > > > > > > > As for the Apache compliance, It's OK to include the vendor source > code > > > in > > > > our repository. We can update the release script and exclude the > vendor > > > > directory when releasing. > > > > > > > > On Sat, Aug 25, 2018 at 4:20 PM Kirin Wang <[email protected]> > > > > wrote: > > > > > > > > > +1 > > > > > But may be we need to confirm if there are Apache compliance issue > > > about > > > > > it ? > > > > > > > > > > Xiaoliang Tian <[email protected]> 于2018年8月25日周六 上午10:48写道： > > > > > > > > > > > +1 Agree > > > > > > the truth is go project can easily go into a dep hell and there > is > > no > > > > dep > > > > > > tool can manage the complicated deps > > > > > > > > > > > > checkout how go project does > > > > > > https://github.com/istio/istio/tree/master/vendor > > > > > > https://github.com/coreos/etcd/tree/master/vendor > > > > > > > > > > > > dep management is torturing go developers now > > > > > > > > > > > > Sure <[email protected]> 于2018年8月25日周六 上午10:39写道： > > > > > > > > > > > > > Developers from China complain it is hard to go get the 3rd > > depends > > > > > > source > > > > > > > code of sc. > > > > > > > I suggest add these source code in vendor directory in sc > > project, > > > > like > > > > > > > Istio and etcd project do. > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best Regards, > > > > Yang. > > > > > > > > > > > > > -- > > Best Regards, > > Yang. > > > -- Best Regards, Yang.
