diff --git a/CHANGELOG b/CHANGELOG
index 68f9ba4f6..f25cd8a18 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -35,6 +35,8 @@ Changes between 1.0.0b3 and 1.0.0b7
 * resolve issue #18, multiprocessing.Manager() and 
   redirection clash 
 
+* make __name__ == "__channelexec__" for remote_exec code
+
 Changes between 1.0.0b1 and 1.0.0b3
 =============================================
 
diff --git a/doc/announce/release-1.0.0.txt b/doc/announce/release-1.0.0.txt
index 372eaf9aa..bf697a77d 100644
--- a/doc/announce/release-1.0.0.txt
+++ b/doc/announce/release-1.0.0.txt
@@ -1,34 +1,49 @@
-py.test / py lib 1.0.0: distributed testing and dynamic code deployment 
+py.test / py lib 1.0.0: new test plugins, funcargs and cleanups 
 ============================================================================
 
 Welcome to the 1.0 release bringing new flexibility and 
-power to testing with Python!  Main news: 
+power to testing with Python.  Main news: 
 
-* new py.test plugin architecture, some examples: 
+* improved test architecture, featuring super-simple project 
+  specific or cross-project single-file plugins, e.g:
 
-  pytest_xfail.py: mark tests as "expected to fail" 
-  pytest_pocoo.py: automatically send tracebacks to pocoo paste service 
-  pytest_monkeypatch.py: safely patch parts of your environment in a test function
-  pytest_figleaf.py: generate html coverage reports 
-  pytest_resultlog.py: generate buildbot-friendly output 
+  * pytest_unittest.py: run traditional unittest.py tests 
+  * pytest_xfail.py: mark tests as "expected to fail" 
+  * pytest_pocoo.py: automatically send tracebacks to pocoo paste service 
+  * pytest_monkeypatch.py: safely patch parts of your environment in a test function
+  * pytest_figleaf.py: generate html coverage reports 
+  * pytest_resultlog.py: generate buildbot-friendly output 
 
-  and much more! 
+  and many more!
 
-* funcargs - the new flexible mechanism for managing all your test setup/fixture needs! 
+* funcargs - bringing new flexibilty and zero-boilerplate to Python testing: 
+
+  - cleanly separated test code and test configuration and test value setup 
+  - ideal for integration and functional tests
+  - new generative tests -> deprecation of yield-generated tests
+
+* distributed testing and distributed execution (py.execnet): 
+
+  - new unified "TX" URL scheme for specifying remote resources 
+  - new sync/async ways to handle multiple remote processes 
+  - much improved documentation 
 
-* flexibly distribute tests to multiple computers from the command line
 
 See the py.test documentation for more info: 
 
     http://pytest.org
 
-The py lib contains the py.test tool and offers its well-tested code 
-independently from the testing tool, mainly:
+The py lib also got smaller and focuses on offering much of the 
+well-tested py.test code in independent namespaces: 
 
 * py.execnet: ad-hoc code distribution to SSH, Socket and local sub processes
-* py.code: support for dynamically running and debugging python code 
+* py.code: higher-level introspection and dynamic generation of python code 
 * py.path: path abstractions over local and subversion files 
 
+Some non-strictly-test related code, notably greenlets/co-routines 
+and apigen now live on their own and have been removed, also simplifying
+the installation procedures. 
+
 The whole package works well with Linux, OSX and Win32, on 
 Python 2.3, 2.4, 2.5 and 2.6.  (Expect Python3 compatibility soon!) 
 
diff --git a/doc/execnet.txt b/doc/execnet.txt
index 1d1373654..fb7835fec 100644
--- a/doc/execnet.txt
+++ b/doc/execnet.txt
@@ -238,3 +238,19 @@ socketserver::
     socketgw = py.execnet.SocketGateway.new_remote(popengw, ("127.0.0.1", 0))
 
     print socketgw._rinfo() # print some info about the remote environment
+
+
+Sending a module / checking if run through remote_exec 
+--------------------------------------------------------------
+
+You can pass a module object to ``remote_exec`` in which case
+its source code will be sent.  No dependencies will be transferred
+so the module must be self-contained or only use modules that are 
+installed on the "other" side.  Module code can detect if it is 
+running in a remote_exec situation by checking for the special 
+``__name__`` attribute like this::
+
+    if __name__ == '__channelexec__':
+        # ... call module functions ... 
+        
+
diff --git a/py/execnet/gateway.py b/py/execnet/gateway.py
index 6a23c0d24..2ea35ae91 100644
--- a/py/execnet/gateway.py
+++ b/py/execnet/gateway.py
@@ -230,7 +230,7 @@ class Gateway(object):
         from sys import exc_info
         channel, (source, outid, errid) = item 
         try:
-            loc = { 'channel' : channel }
+            loc = { 'channel' : channel, '__name__': '__channelexec__'}
             self._trace("execution starts:", repr(source)[:50])
             close = self._local_redirect_thread_output(outid, errid) 
             try:
diff --git a/py/execnet/testing/test_gateway.py b/py/execnet/testing/test_gateway.py
index 7b8514e38..4792354a0 100644
--- a/py/execnet/testing/test_gateway.py
+++ b/py/execnet/testing/test_gateway.py
@@ -92,6 +92,11 @@ class BasicRemoteExecution:
     def test_repr_doesnt_crash(self):
         assert isinstance(repr(self), str)
 
+    def test_attribute__name__(self):
+        channel = self.gw.remote_exec("channel.send(__name__)")
+        name = channel.receive()
+        assert name == "__channelexec__" 
+
     def test_correct_setup_no_py(self):
         channel = self.gw.remote_exec("""
             import sys