ANNOUNCE: GNU Mailman 3.0a2 (Grand Designs)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Mailpersons,
I'm happy to announce the availability of GNU Mailman version 3.0
alpha 2, code name "Grand Designs".
Of course, this is still an alpha snapshot and not suitable for
production systems, however there is a lot of good functional stuff in
this release that is worthy of a look. Because this is still alpha
software, you can have a big influence on where the code goes from
here. I'm especially interested in feedback from integrators, and I
welcome your contribution.
Mailman 3.0 alpha 2 should be functional enough to create mailing
lists, connect them to your MTA, add and remove members, and send
email to those lists. Incoming mail integration is currently only
supported for Postfix via LMTP; contributions for other MTAs and
incoming mechanisms are welcome. The web interface is still not
functional, so for now you have to interact with Mailman via the
command line.
Please feel free to discuss Mailman 3 development on the mailman-
developers mailing list. You can submit branches and bugs to the
Launchpad bug tracker at https://bugs.launchpad.net/mailman
For detailed information on 3.0a2, please read docs/ALPHA.txt. This
file explains how to build Mailman and run the test suite. The docs/
NEWS.txt file contains high level descriptions of what's changed since
3.0a1. Most notably are the new configuration system, the better test
suite and installation process, and the new LMTP support. Mailman 3
also contains extensive doctests which explain how certain subsystems
work.
Please note that Python 2.6 is required.
You can download the tarball either from the Cheeseshop or from
Launchpad. An egg is available on the Cheeseshop. See:
http://pypi.python.org/pypi/mailman/3.0.0a2 https://launchpad.net/mailman/+download
for details.
I hope you find this second snapshot useful and encouraging. Please
participate!
Enjoy, B.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAklfuV8ACgkQ2YZpQepbvXGRzACeLPvX9eeaPj4x9viw6qZqxgUA sawAn0iDsOHBMM6+RzfUJSQX9RORZTy/ =tTMG -----END PGP SIGNATURE-----
On Sat, Jan 03, 2009 at 02:15:42PM -0500, Barry Warsaw wrote:
Because this is still alpha software, you can have a big influence on where the code goes from here. I'm especially interested in feedback from integrators, and I welcome your contribution.
[...]
Please feel free to discuss Mailman 3 development on the mailman- developers mailing list. You can submit branches and bugs to the Launchpad bug tracker at https://bugs.launchpad.net/mailman
Looks like the preference for feature requests (going by launchpad, and the list archive) is here...
in which case, I'm wondering how possible it would be for something along the lines of the following to be implemented (my python is ridiculously lousy; were I to write something like this, it would probably be a webform, some perl, mysql, cron, and bash interacting with add_members (i'm not really pro the idea of piping things to wrappers, as has been mooted in the past on -users &c).
Here's the proposal --
I'd like a third level of password authentication to be
added to allow those with said password to be able to
access the 'subscribe members' web form
(admin/foo/members/add, currently), and that alone:
*without* being able to see the existing list of list-members,
and for tertiary-admin actions (for lack of better phrase) to
be logged in the usual fashion.Perhaps a little explanation, we in this case is a privacy campaign, and we'd like our local-level co-ordinators to be able to add the email addresses of their local supporters to their lists, but not
(a) change any of the settings, or
(b) see the list of subscribers once inputted.The hopeful outcome will be that we can let these local-co-ords do this, via an "official" mechanism, rather than home-bru. It's safe to assume that the email addressess have been given in good faith, and consent to be subscribed has been given.
Behind the scenes, it would be useful if unable to subscribe notifications were sent to $LIST-OWNER (or just logged), but for only non-validating addys to be printed on-screen (quite often we see no SLD/TLD), with a note along the lines "for privacy reasons, we're only going to tell you of the successes" when the password is that of the 3ry-user (but the admin user gets to see all, as current)
What would also be nice is for something like bin/change_pw to handle the password creation/modification, and to mail the 3ry-admin with the password and URI, along with some other (template) blurb.
Any thoughts? Would this be possible to build? Could it be included. please?
- Barry Warsaw <barry@list.org>:
For detailed information on 3.0a2, please read docs/ALPHA.txt. This
file explains how to build Mailman and run the test suite. The docs/ NEWS.txt file contains high level descriptions of what's changed since
3.0a1. Most notably are the new configuration system, the better test
suite and installation process, and the new LMTP support. Mailman 3
also contains extensive doctests which explain how certain subsystems
work.
I'm having problems to build MM3 and I am unexperienced enough with Python (including bzr) to tell if its me or any program standing in the way.
So far I have successfully built Python 2.6 on a vanilla Ubuntu/Hardy virtual machine.
Then I followed docs/ALPHA.txt from mailman-3.0.0a2 and tried to checkout megamerge. I get this and believe I shouldn't:
# bzr branch lp:~barry/lazr.config/megamerge bzr: ERROR: Not a branch: "https://code.launchpad.net/".
I can't tell if its a configuration error on my side or a real error. Any help greatly appreciated.
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Patrick Koetter Tel: 089 45227227 Echinger Strasse 3 Fax: 089 45227226 85386 Eching Web: http://www.state-of-mind.de
Amtsgericht München Partnerschaftsregister PR 563
Patrick Ben Koetter wrote:
Then I followed docs/ALPHA.txt from mailman-3.0.0a2 and tried to checkout megamerge. I get this and believe I shouldn't:
# bzr branch lp:~barry/lazr.config/megamerge bzr: ERROR: Not a branch: "https://code.launchpad.net/".
I can't tell if its a configuration error on my side or a real error. Any help greatly appreciated.
It seems to be a real error. I don't see that branch on launchpad, and I can't get it either.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jan 18, 2009, at 2:59 PM, Patrick Ben Koetter wrote:
- Barry Warsaw <barry@list.org>:
For detailed information on 3.0a2, please read docs/ALPHA.txt. This file explains how to build Mailman and run the test suite. The docs/ NEWS.txt file contains high level descriptions of what's changed
since 3.0a1. Most notably are the new configuration system, the better
test suite and installation process, and the new LMTP support. Mailman 3 also contains extensive doctests which explain how certain subsystems work.I'm having problems to build MM3 and I am unexperienced enough with
Python (including bzr) to tell if its me or any program standing in the way.So far I have successfully built Python 2.6 on a vanilla Ubuntu/ Hardy virtual machine.
Then I followed docs/ALPHA.txt from mailman-3.0.0a2 and tried to
checkout megamerge. I get this and believe I shouldn't:# bzr branch lp:~barry/lazr.config/megamerge bzr: ERROR: Not a branch: "https://code.launchpad.net/".
I can't tell if its a configuration error on my side or a real
error. Any help greatly appreciated.
The megamerge branch was merged into lazr.config proper and release as
lazr.config 1.1. So you don't need this branch. The bzr branch of
mm3.0 is up-to-date now, but from the tarball, you should just skip
this step and edit buildout.cfg so that the "develop" line only
contains a single dot.
Note that bin/test may break for you. If it does, I have a
workaround, but I don't yet know if the problem is in buildout or
mailman.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkl0j3UACgkQ2YZpQepbvXHMpQCgkUn18wfHD/CzyYFdHwGP5FPC dFkAniwvzKfba/02c4xWtaF53Rz2+acA =dlOn -----END PGP SIGNATURE-----
- Barry Warsaw <barry@list.org>:
The megamerge branch was merged into lazr.config proper and release as
lazr.config 1.1. So you don't need this branch. The bzr branch of mm3.0 is up-to-date now, but from the tarball, you should just skip this step and edit buildout.cfg so that the "develop" line only contains a single dot.Note that bin/test may break for you. If it does, I have a workaround, but I don't yet know if the problem is in buildout or mailman.
It worked, more or less:
Ran 29 tests with 0 failures and 4 errors in 0.407 seconds. Tearing down left over layers: Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
Test-modules with import problems: eggs.lazr.config-1.1-py2.6.egg.lazr.config.tests eggs.lazr.delegates-1.0-py2.6.egg.lazr.delegates.tests eggs.zc.buildout-1.1.1-py2.6.egg.zc.buildout.tests eggs.zc.buildout-1.1.1-py2.6.egg.zc.buildout.testselectingpython eggs.zc.recipe.egg-1.1.0-py2.6.egg.zc.recipe.egg.tests eggs.zc.recipe.testrunner-1.1.0-py2.6.egg.zc.recipe.testrunner.tests eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.common.tests.test_idatetime eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.common.tests.test_import_interfaces eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_adapter eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_advice eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_declarations eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_document eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_element eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_interface eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_odd_declarations eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_sorting eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_verify eggs.zope.testing-3.7.1-py2.6.egg.zope.testing.tests eggs.zope.testing-3.7.1-py2.6.egg.zope.testing.testrunner.tests Total: 94 tests, 0 failures, 4 errors in 11.174 seconds.
Proceed to create mailman.cfg or wait for workaround?
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Patrick Koetter Tel: 089 45227227 Echinger Strasse 3 Fax: 089 45227226 85386 Eching Web: http://www.state-of-mind.de
Amtsgericht München Partnerschaftsregister PR 563
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jan 19, 2009, at 3:08 PM, Patrick Ben Koetter wrote:
- Barry Warsaw <barry@list.org>:
The megamerge branch was merged into lazr.config proper and release
as lazr.config 1.1. So you don't need this branch. The bzr branch of
mm3.0 is up-to-date now, but from the tarball, you should just skip this
step and edit buildout.cfg so that the "develop" line only contains a
single dot.Note that bin/test may break for you. If it does, I have a
workaround, but I don't yet know if the problem is in buildout or mailman.It worked, more or less:
Ran 29 tests with 0 failures and 4 errors in 0.407 seconds. Tearing down left over layers: Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
Test-modules with import problems: eggs.lazr.config-1.1-py2.6.egg.lazr.config.tests eggs.lazr.delegates-1.0-py2.6.egg.lazr.delegates.tests eggs.zc.buildout-1.1.1-py2.6.egg.zc.buildout.tests eggs.zc.buildout-1.1.1-py2.6.egg.zc.buildout.testselectingpython eggs.zc.recipe.egg-1.1.0-py2.6.egg.zc.recipe.egg.tests eggs.zc.recipe.testrunner-1.1.0-py2.6.egg.zc.recipe.testrunner.tests eggs.zope.interface-3.5.0-py2.6-linux- x86_64.egg.zope.interface.common.tests.test_idatetime eggs.zope.interface-3.5.0-py2.6-linux- x86_64.egg.zope.interface.common.tests.test_import_interfaces eggs.zope.interface-3.5.0-py2.6-linux- x86_64.egg.zope.interface.tests.test_adapter eggs.zope.interface-3.5.0-py2.6-linux- x86_64.egg.zope.interface.tests.test_advice eggs.zope.interface-3.5.0-py2.6-linux- x86_64.egg.zope.interface.tests.test_declarations eggs.zope.interface-3.5.0-py2.6-linux- x86_64.egg.zope.interface.tests.test_document eggs.zope.interface-3.5.0-py2.6-linux- x86_64.egg.zope.interface.tests.test_element eggs.zope.interface-3.5.0-py2.6-linux- x86_64.egg.zope.interface.tests.test_interface eggs.zope.interface-3.5.0-py2.6-linux- x86_64.egg.zope.interface.tests.test_odd_declarations eggs.zope.interface-3.5.0-py2.6-linux- x86_64.egg.zope.interface.tests.test_sorting eggs.zope.interface-3.5.0-py2.6-linux- x86_64.egg.zope.interface.tests.test_verify eggs.zope.testing-3.7.1-py2.6.egg.zope.testing.tests eggs.zope.testing-3.7.1-py2.6.egg.zope.testing.testrunner.tests Total: 94 tests, 0 failures, 4 errors in 11.174 seconds.
Proceed to create mailman.cfg or wait for workaround?
That's the failure I get too. It looks to me like zope.testing is
putting some bogus eggs on sys.path. I need to contact the distutils
sig to find out what the problem is.
In the meantime, remove the buildout artifact directories (basically
anything that 'bzr ignored' spits out), then add the following in your
~/.buildout/default.cfg file (creating the directory if necessary):
[buildout] eggs=directory=/home/you/.buildout/eggs download-cache=/home/you/.buildout/download-cache
Then rebuild. This basically just moves the eggs out of a location
that seems to confuse testrunner.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSXTmOHEjvBPtnXfVAQIQNAP/YSthTDsS8GisTwoq4xo1D5T0K+Gqxtxh EjXuqcFDCEVYDzz65xPPq7BrjeEvUlQw8cy+PO6ECswd18+cY5IxN6Rh2B0o59ei dY78bkVpMpluGvUctLLvlT8SezH7sLdHWCSbdJDbE5i3N9wBTzUpt5qc7a6JkM6V luokXRTZX0A= =jxsk -----END PGP SIGNATURE-----
participants (5)
-
Adam McGreggor -
Barry Warsaw -
Barry Warsaw -
Mark Sapiro -
Patrick Ben Koetter