Reviews are very exciting, but seem to be unable to fit the following use case:
I want to setup a repo such that a subset of collaborators (or organization members) can merge reviewed PRs to protected branches. I want the rest of the users to be able to create new branches and submit PRs from them, but _not_ to be able to push to protected branches. They should _only_ be able to land code in protected branches via reviewed PRs (via the merge button).
Is there a way to achieve this now that I'm missing? Gitlab's more granular user roles + permissions allow this.
Can you reference the part of the proposal that states this? I'm reading the following points:
> $GOPATH/src/foo will be imported as foo by non-main package $GOPATH/src/mypkg/p.
> $GOPATH/src/mypkg/external/foo will be imported as foo by a non-main package p anywhere, when p is being built as a dependency of command $GOPATH/src/mypkg/c.
It seems to me this is saying that libraries will use external packages only when built as a dependency of a main package. Again, this means library authors are out of luck.
Am I understanding correctly that this proposal again side steps / ignores pinning dependencies for libraries? To me, this is the biggest current problem in the ecosystem and, as a library author, this doesn't solve any of my issues. I hope I misread somehow.
How is this different from godep[1] other than being the root of its own GOPATH and having a different naming convention for the location of vendored dependencies?
This whole "framework fatigue" thing is going reductio ad absurdum. Convenience is not bad. _Too_ much convenience traded for opacity is bad.
As someone with a Phoenix app running in production, I can tell you that this framework hits the sweet spot of providing lots of value without requiring the user to learn too much. The abstractions it provides, especially the router and rendering layers, are very welcome. And I'm saying this from the perspective of someone who has built a few smaller vanilla plug applications.
Let's not throw the baby out with the bath water here just because rails went a little too far with the magic.
I think the point is, if you write map like this you might as well be using a dynamically typed language in the first place because you're deriving no benefit from the type checker. In fact, you're just using casting to completely circumvent it.
From what I've read/seen, the go blocks are lightweight thread-like processes multiplexed onto a thread pool. You may be correct about using Thread/sleep, ideally I would have used (timeout ...) and then pulled off the channel. However, I didn't want to introduce the concept of channels too early in the post, so I felt Thread/sleep worked as a compromise.
I want to setup a repo such that a subset of collaborators (or organization members) can merge reviewed PRs to protected branches. I want the rest of the users to be able to create new branches and submit PRs from them, but _not_ to be able to push to protected branches. They should _only_ be able to land code in protected branches via reviewed PRs (via the merge button).
Is there a way to achieve this now that I'm missing? Gitlab's more granular user roles + permissions allow this.