I would go with vendoring and proper education combined with peer review. The hoops you go through to maintain "control" seems awkward at best. I mean, you do after all trust the developers with you production code...
On Fri, Jan 6, 2017, 20:16 Jacek Furmankiewicz <jace...@gmail.com> wrote: > I doubt that will fly. Once again there is little control. > Any developer can pull in any package they want and bypass central control > mechanism. > > The HTTP proxy suggestion seems ingenious...but pretty hard to implement > from a network perspective. > > We have developers in the office, we have developers remotely, some on VPN > within company network, some not (only connect to VPN once a day to get > access to internal network resources). > People often work from home, etc. > > So enforcing the HTTP proxy from all these places is unrealistic. > > If a developer works from home, nothing stops him from pulling from > Internet via go get bypassing the proxy. Then he/she comes into the office > next day with their laptop to prepare a PR and all these controls are > bypassed. > Code that shouldn't be there can get committed without any license review. > > We had a team of JS programmers who used to that and the end result was a > ton of libraries checked into our UI source code repositories that never > went through proper license review. > There were disciplinary actions as a result, so this is no laughing matter. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
