Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:

$ git clone -b "serial-driver" git@github.com:janeczku/machine.git somewhere
$ cd somewhere
$ git rebase -i HEAD~3
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

It's not so simple unfortunately. If other driver plugins are in the wild and they don't have the SerialDriver method, everything will go kaboom. Not to mention that, I'd prefer to avoid adding yet another method to the already heavily overloaded Driver interface at all costs.

At any rate, if we're going to break API compatibility and urge driver plugin authors to update, I'd prefer to actually solve some of the problems that we're facing (e.g. rate limits) more elegantly (ideally we should have one "provider" process which can batch requests to APIs if required instead of our current one-driver-per-process model).

In that respect, I would really love to see some proposals for a V2 API in the issues.

@nathanleclaire

It's not so simple unfortunately. If other driver plugins are in the wild and they don't have the SerialDriver method, everything will go kaboom.

Hold on, v0.5.1 in fact broke API compatibility and made v0.5.0 drivers go kaboom. So how is the fact that authors need to recompile their plugins to keep compatibility with the latest machine releases a valid argument for rejecting this PR? They need to do so as it is already.

At any rate, if we're going to break API compatibility and urge driver plugin authors to update...

I don't know what exactly you mean by update. You mean their code?
The SerialDriver method is implemented by the BaseDriver and defaults to false. There is no need for any author to change anything in his code.

In that respect, I would really love to see some proposals for a V2 API in the issues.

Thats all very nice. But the one-server-per-machine model causes problems right now. And making the SerialDriver globally available is a perfectly good solution. And above that hardcoding special treatment for certain drivers (like the SerialDriver for virtualbox) kind of contradicts the plugin model anyway.

Hold on, v0.5.1 in fact broke API compatibility and made v0.5.0 drivers go kaboom

How so? I haven't heard any bug report of this. Please file one since it's critical for me to know if 0.5.1 has broken 0.5.0 plugins. I know there were some shakeups during the RCs, but those are RCs. If this happened, it was very unintentional.

I don't know what exactly you mean by update. You mean their code?

Re-compile and re-distribute their plugin binaries. Otherwise their servers won't have this method you're calling here.

Thats all very nice. But the one-server-per-machine model causes problems right now. And making the SerialDriver globally available is a perfectly good solution. And above that hardcoding special treatment for certain drivers (like the SerialDriver for virtualbox) kind of contradicts the plugin model anyway.

I'm not happy about the special treatment for virtualbox and really want to work towards a general solution (the current hack is a definite band-aid). But ensuring driver operations only happen one-at-a-time for cloud providers will not prevent rate limiting from happening. It might seem to help, but the issue will still exist. The same number of API calls are being made, they just happen more slowly.