timmow

One problem is the library as it stands doesn't match up to composers namespacing requirements - which some php developers have decided they don't like and therefore are not going to support

We use vanilla forums for comments, and its been excellent

The number one feature I wish github would add is a setting to prevent force pushing to master, but allow a forced push to all other branches. This would allow us to use a branching model like http://scottchacon.com/2011/08/31/github-flow.html but we would still be able to rebase branches after code review, without the danger of rewriting history on the master branch. You can do something similar with client side hooks, but it would be nice if it was supported server side.

If you want a completely accurate history I hope you have your editor set to commit after every character you type, in case you need to delete a typo.

Ok, thats slightly tongue in cheek, but I think its a subtle balance between clean and accurate history, some people are happy to use rebase to, some are not. In my view, rebasing is no different to using undo in your editor, but I appreciate some people feel differently.

I do something similar with local port forwarding in ssh - I can also use this to open files on remote servers in local gui editors, and to send things to notification centre - useful if you leave a long running task in the background.

This seems to me to be an issue that there is some disagreement on between devs and ops people - most devs are happy to distribute software with a Gemfile and see it as a solved problem. Ops packages tend to go the omnibus route like Chef has, or use Jruby and package as a Jar file like http://logstash.net/

I wonder if there is anything developers can do as a community to help solve the problems these distributors feel they have?

Are you considering adding alarm support to wake the mac and play a radio station in the morning? I would love a reliable mac program to do this!

Many CDNs charge a lot (10x for all bandwidth, including non secure) for https. If you are fronting one of your sites with these, it is not economically viable to switch over.

Public projects and the need to add every single developer to every single project they needed access to (no concept of teams) were the main reasons we moved from Gitlab to Github Enterprise

A bit more on the devops role - we are looking for a developer interested in infrastructure or a sysadmin interested in development to help work on our puppet / mcollective managed platform, produce tools to help developers productivity, and work on metrics collection / visualisation, as well as some more strategic development work on the high traffic consumer websites. All in a fantastic office next to the tate modern. If you are interested, email Joseph above.