On Fri, Feb 5, 2016 at 8:51 PM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
This has been reviewed by merchants, miners and exchanges for a couple of weeks, and has been implemented and tested as part of the Bitcoin Classic and Bitcoin XT implementations.

Constructive feedback welcome; argument about whether or not it is a good idea to roll out a hard fork now will be unproductive, so I vote we don't go there.

Draft BIP:

Summary:  
  Increase block size limit to 2,000,000 bytes.
  After 75% hashpower support then 28-day grace period.
  With accurate sigop counting, but existing sigop limit (20,000)
  And a new, high limit on signature hashing

Blog post walking through the code:

It's great to finally see a BIP, although seems strange to ask for feedback after releasing binaries.

In any case, the issue isn't about "whether or not it is a good idea to roll out a hard fork", the question has always been about how to do safe hard fork deployment and what the technological requirements are for doing so. Your BIP/blogs do not actually address any of this. 75% miner signalling with a 28 day flag day thereafter gives virtually no time for the entire ecosystem to migrate and is widely considered unsafe. It's plainly obvious that an entire ecosystem of 5000 full nodes cannot be prepared in a month.