I just saw Erik's reply to this, hadn't noticed your original post until now.
On Fri, May 19, 2017 at 07:22:20AM +1000, Piers Rowan wrote: > We have grown quite a bit and having each dev running their pet dev > environment seems eclectic and difficult to manage (aka manage down > when you need to help a colleague and it take you 5 minutes to work > out how their IDE / screen is working). Іf you want an absolutely certain way to totally destroy a developer's productivity, force them to use your (or someone else's) preferred IDE. or worse, an IDE chosen by committee/consensus. As long as they're committing their changes regularly to the version control system, and following the required coding style, let each of them use what they want. Otherwise you're forcing them to throw away years of experience with their tools. Also, they're almost certainly going to keep using their own preferred tools at home, so they'll suffer a jarring context switch every day when they come in to work. Nominate a preferred or supported IDE if you want but don't force everyone to use it. If you're using git for version control (and why wouldn't you?), gitlab is a pretty good tool for running your own github-like source repository, issue/task tracker, developer wiki, built-in CI tools (e.g. you can configure it to automatically try to compile the software on every commit and report the outcome to the developer), and more. https://about.gitlab.com/ Packaged for debian and presumably other distros. and trivially easy to get a tєst site up and running if you have a docker host somewhere (docker image at https://hub.docker.com/r/gitlab/gitlab-ce/). gitlab has a "community edition" and an "enterprise edition". AFAICT, there isn't much difference between the two, mostly paid support and some niceties useful mainly for very large sites: https://about.gitlab.com/comparison/gitlab-ce-vs-gitlab-ee.html I run gitlab on my own server to manage my own software projects (many of which are also on github), as well as for documentation and other writing projects larger than a half-page readme (i'm a huge fan of vim + markdown + pandoc + a Makefile + git for a great writing workflow: markdown is the "source code", and html, .odt, .epub and .pdf are the pandoc-"compiled" output formats). I use only a small subset of gitlab's features, but it works well for me. craig -- craig sanders <[email protected]> _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
