OH GOD.
I can honestly say that I feel comfortable enough to speak for a good chunk of the community when I say that I am certain that many users would feel alot better if you had NOTHING to do with CGMiner, it's upkeep or it's forward/further development.
You don't speak for me, and I am not sure you even speak for a good chunk.
Here you go "detective":
http://rusty.ozlabs.org/?p=196I want the best possible code, putting a purity test of code (which is pure logic) is just asinine. Luke has found bugs (and fixes) in cgminer and bitcoind. Would the community be better served by running buggier software because you dislike him. As long as merges are vetted and not done without Due Diligence I honestly don't care if the unibomber wants to make a pull request.
Either the code changes have value or they doesn't. THAT (and only that) should be the metric. To try and get this somewhat back on topic
my opininon is that changes to the interface on cgminer should be a low priority. The API paid for by many of us, coded by Kano, and integrated and tested by conman provide the perfect path forward. Nobody will ever agree on perfect interface. There is no such thing. The API allows multiple front ends to be developed independently of cgminer.
It allows separation of responsibilities:
kernel = hashing engine
cgminer = control & management
GUI = user interface, reporting, charting, etc
cgminer just needs enough of a native interface to allow low level troubleshooting. So many people cling to the obsolete GUIminer that I am surprised nobody has made a Windows GUI interface for cgminer (maybe I should).