On Fri, Jan 6, 2017 at 8:38 PM Jacek Furmankiewicz
wrote:
>
> We've had really difficult individuals who refused to be bothered with
> going through proper license review.
> Some of them don't work here any more.
>
>
This is a social problem with the people you've hired, or with how they
have bee
I've seen this sort of question on the mailong list before. Probably a good
idea to gather potential solutions on the Wiki somewhere.
Damian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emai
You asked a solution for your locked-down build servers, what the proxy
solution solves easily.
For developer lock-in, you have to create a git hook to limit to libraries only
in the repo mirror.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
in theory, sure. In practice, not always.
We've had really difficult individuals who refused to be bothered with
going through proper license review.
Some of them don't work here any more.
In once case it was a team lead, so peer review would not work, since the
whole team "learned" to ignore p
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 wrote:
> I doubt that will fly
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 develop
On Sat, Jan 7, 2017, 8:00 AM Justin Israel wrote:
>
>
> On Sat, Jan 7, 2017, 6:53 AM Jacek Furmankiewicz
> wrote:
>
> Thank you for your answer.
>
> Issue is that it really is not much control with this approach.
>
>
> If you used the suggestion from Tam's,
>
Silly autocorrection. I meant Tamás
On Sat, Jan 7, 2017, 6:53 AM Jacek Furmankiewicz wrote:
> Thank you for your answer.
>
> Issue is that it really is not much control with this approach.
>
If you used the suggestion from Tam's, to have a small http proxy which
directs "go get" at your Stash, that could do the same thing as your
Thank you for your answer.
Issue is that it really is not much control with this approach.
Any developer could potentially pull any package, avoid license review and
just commit it to their project.
So there is no central point of control that can limit which libraries
(exactly down to particul
Jacek--
In a similar setup (must be able to build without internet access) we
simply used glide on the developer machines, then used
https://github.com/Masterminds/rmvcsdir to remove vcs stuff and commit
full deps to our local version control -- then all that is needed to
build is to clone it an
Hi everyone,
We are operating in a SOC2 environment, which our customers demanded as we
host their systems and their data.
It's a common requirement for many companies in a cloud environment.
One of the key requirements of SOC2 is that *all* external
libraries/depdencies are mirrored internally
11 matches
Mail list logo
