Hello Barry (and all),
I may have a few more coming from my colleagues regarding this, but I do have one point I'd like to mention. Not sure if it's ever been given thought.
Currently, Mailman looks at the list-name as strictly "list-name", instead of "list-name@domain". Why I bring this up?
I have a set of servers (eight, in fact) running several thousand lists (about 10,000 of them), all from different people with different domains. Many of these users often pick the same list name, which we of course make them pick a new list name. Reason being, having two list names identical on one server causes delivery problems, file storage, database problems, log problems, the works.
Is there any consideration made, or is it possible to have Mailman recognize that "listname@domaina.com" is different than "listname@domainb.com", and operate as normal based on that?
Just a thought. :-) Glad to see Mailman on the move! Krystal
----- Original Message ---- From: Barry Warsaw barry@python.org To: Mailman Developers Mailman-Developers@python.org Cc: Mailman Users mailman-users@python.org Sent: Saturday, July 7, 2007 12:36:54 PM Subject: [Mailman-Users] Mailman roadmap
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sorry, I forgot to cross-post this to mailman-users, so I'm reposting.
- -Barry
Now that we've successfully navigated the switch to Bazaar, it's time to lay out plans for future Mailman releases. I've talked to several people about what to do about Mailman's future and I'd like to take this opportunity to describe my thoughts and get your feedback. First some background.
Mailman 2.1 is (shockingly) four and a half years old, having been initially released on 30-Dec-2002. The last release in the series, 2.1.9 was made almost a year ago. In the meantime, Mark and Tokio have been doing a great job maintaining the 2.1 branch, with several important patches in the tree now that will eventually become 2.1.10. The problem of course is that we can't add any new features to the 2.1 family <wink>, so we should be thinking about a new major release.
I've been making good progress on the SQAlchemy/Elixir version, which will finally get rid of pickles and put Mailman on a Real Database (tm). It's been clear to me for a while that this branch will have a unified user database. It simply makes no sense to build the database back-end without once and for all fixing this design constraint. I've always said that the unified user database will be in Mailman 3, and thus this branch is indeed called "Mailman 3.0".
I've been slowly building things back up from the ground floor. The basic data model is in pretty good shape and I'm taking a religious test-driven approach to making things work again. But the branch still needs a lot of work, and I have no ETA for Mailman 3.0.
In the meantime, Andrew Kuchling and others have volunteered to work on modernizing the Mailman web u/i, and Terri recently started a thread discussing updates to the archiver. I think it makes sense to bless these efforts, towards the goal of releasing them in Mailman 2.2. I intend to create an official Mailman 2.2 branch in bzr where these efforts can land as they mature. My hope of course is that we'll also be able to use much of this new code for Mailman 3.
I'd like to keep the changes for 2.2 focused on the web u/i and archiver, with a small number of additional features to be determined. Mailman 2.2 should see no changes to the basic architecture or 'database'; we'll continue to use pickles by default for Mailman 2.2. While I won't rule out other new features, I want to be very picky about those that are accepted for 2.2, and would not feel bad at all if we rejected or deferred until 3.0 most of those proposed. Criteria for other 2.2 features must include minimal code impact with a high degree of reliability and stability.
I plan on updating the wiki pages to reflect this thinking, but I would like to get feedback from y'all about the plan. It would be awesome if we could see a release of Mailman 2.2 some time in late 2007 or early 2008.
Comments, question?
- -Barry
On Jul 7, 2007, at 3:23 PM, Krystal F. Zipfel wrote:
Currently, Mailman looks at the list-name as strictly "list-name",
instead of "list-name@domain".
This is by far and away my biggest "feature request" as well. Each
virtual
domain should be its own private name space for list names.
I also think that the other grander suggestions are good. It is
important to get those things sorted out well. But my most immediate
concern is avoiding list name collisions across (pseudo) virtual
domains.
-j
-- Jeffrey Goldberg http://www.goldmark.org/jeff/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jul 7, 2007, at 4:23 PM, Krystal F. Zipfel wrote:
Is there any consideration made, or is it possible to have Mailman recognize that "listname@domaina.com" is different than "listname@domainb.com", and operate as normal based on that?
Hi Krystal,
I don't expect 2.2 to be any different than 2.1 in this regard,
however this is already fixed in the Mailman 3 dev branch.
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iQCVAwUBRpDXR3EjvBPtnXfVAQJbrgQAs8EpZonUOEprpyXS5YpeJN1IqYsc6+Da j5fmMGQdI0kjSWQXrkc40z+IJkaGITO6o8nKjilHUUH2D6VRTzOiZxVS5Wj7dyrF IxU5S9qKWHA0NqFJWwiCZRcdR9d83Bl5eFpV946uc0ja0CCv8Qebv28CpkVyNhat 29NBhFbXfZc= =m/ht -----END PGP SIGNATURE-----
On Sun, 8 Jul 2007, Barry Warsaw wrote:
On Jul 7, 2007, at 4:23 PM, Krystal F. Zipfel wrote:
Is there any consideration made, or is it possible to have Mailman recognize that "listname@domaina.com" is different than "listname@domainb.com", and operate as normal based on that?
I don't expect 2.2 to be any different than 2.1 in this regard, however this is already fixed in the Mailman 3 dev branch.
I would like to register a "+1" towards at least the beginnings of proper, multiple-domain support. No need at all for this to be the whole thing, but at least its basic foundations. Even just a hidden "own-risk" installation option of having the listnames (and references to them) internally stored and processed as "listname@domain-X.com" would help.
What worries me about the "fixed in the Mailman 3 dev branch" is the timescale. You mention both that "2.1 is (shockingly) 4.5 years old", and that there is "no ETA for Mailman 3.0".
So with such a basic, minimal foundation (for true multiple domains) in place, then those of us who would really like it a.s.a.p. in our service environments (i.e. not Mailman 3) would be able to contribute to building it, perhaps as a subproject (analogous to those you mention for "SQAlchemy/Elixir", archiver, "web u/i", etc.).
Anyway, thanks for your work over the years,and now on Mailman. It is much appreciated!
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : UNIX Team Leader Durham University : : South Road : : http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jul 9, 2007, at 4:28 AM, David Lee wrote:
I would like to register a "+1" towards at least the beginnings of
proper, multiple-domain support. No need at all for this to be the whole
thing, but at least its basic foundations. Even just a hidden "own-risk" installation option of having the listnames (and references to them) internally stored and processed as "listname@domain-X.com" would help.
My suggestion would be to investigate some of the unofficial patches
that provide this, or look into using the Site.py hack for this. The
problem with putting something better (even as use-at-your-own-risk)
in 2.2 is that it's a fairly fundamental change to the architecture
of the system so it would require fairly extensive testing. That's
why I really want to defer this to 3.0.
What worries me about the "fixed in the Mailman 3 dev branch" is the timescale. You mention both that "2.1 is (shockingly) 4.5 years
old", and that there is "no ETA for Mailman 3.0".
Right. I'm not ready to commit to a schedule yet, but it's basically
all I'm working on right now.
So with such a basic, minimal foundation (for true multiple
domains) in place, then those of us who would really like it a.s.a.p. in our
service environments (i.e. not Mailman 3) would be able to contribute to
building it, perhaps as a subproject (analogous to those you mention for "SQAlchemy/Elixir", archiver, "web u/i", etc.).
You can do this now. Start an unofficial branch of Mailman 2.2,
publish it, and contribute some code. If you surprise me about the
scope of the changes necessary, we can consider it for 2.2 proper.
This would be an ideal test of the power of using Bazaar. If you're
interested in this, let's move the discussion over to mailman-
developers.
Anyway, thanks for your work over the years,and now on Mailman. It is much appreciated!
My pleasure!
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iQCVAwUBRpIV/HEjvBPtnXfVAQLmdAP6A47uRwzcCBZ81Xao1OcoCjIPC+6c0sAd wUtWPPzdkqp05sNAMQK3r22nH1d7ZRMVODhj01FcM/L+CGyRvH3tJtGT9WJOozIX EeeehHPkZhS82nXWopPHE1y8J5DrgNrO0zujZZivOVufRN0ToqXSNGV8VYhn+jp6 EuNq0FxAo+w= =zdju -----END PGP SIGNATURE-----
I'd like to add a +1 for multiple domain support as well.
When I selected Mailman almost a year ago I remember this feature being on the 2.2 feature list... Developing software myself I fully understand how it has moved to 3.x.
At the same time, maybe a limit to what goes into 2.2 so that 3.x doesn't keep moving either ?
In Service,
Michael Kabot President - SOAR Scouting Online Affordable & Reliable mkabot@soarol.com 585-388-0211
www.soarol.com
| -----Original Message----- | From: mailman-users-bounces+mkabot=soarol.com@python.org | [mailto:mailman-users-bounces+mkabot=soarol.com@python.org] On Behalf | Of Barry Warsaw | Sent: Monday, July 09, 2007 7:03 AM | To: David Lee | Cc: mailman-users@python.org | Subject: Re: [Mailman-Users] Mailman roadmap | | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA1 | | On Jul 9, 2007, at 4:28 AM, David Lee wrote: | | > I would like to register a "+1" towards at least the beginnings of | > proper, | > multiple-domain support. No need at all for this to be the whole | > thing, | > but at least its basic foundations. Even just a hidden "own-risk" | > installation option of having the listnames (and references to them) | > internally stored and processed as "listname@domain-X.com" would | help. | | My suggestion would be to investigate some of the unofficial patches | that provide this, or look into using the Site.py hack for this. The | problem with putting something better (even as use-at-your-own-risk) | in 2.2 is that it's a fairly fundamental change to the architecture | of the system so it would require fairly extensive testing. That's | why I really want to defer this to 3.0. | | > What worries me about the "fixed in the Mailman 3 dev branch" is the | > timescale. You mention both that "2.1 is (shockingly) 4.5 years | > old", and | > that there is "no ETA for Mailman 3.0". | | Right. I'm not ready to commit to a schedule yet, but it's basically | all I'm working on right now. | | > So with such a basic, minimal foundation (for true multiple | > domains) in | > place, then those of us who would really like it a.s.a.p. in our | > service | > environments (i.e. not Mailman 3) would be able to contribute to | > building | > it, perhaps as a subproject (analogous to those you mention for | > "SQAlchemy/Elixir", archiver, "web u/i", etc.). | | You can do this now. Start an unofficial branch of Mailman 2.2, | publish it, and contribute some code. If you surprise me about the | scope of the changes necessary, we can consider it for 2.2 proper. | This would be an ideal test of the power of using Bazaar. If you're | interested in this, let's move the discussion over to mailman- | developers. | | > Anyway, thanks for your work over the years,and now on Mailman. It | is | > much appreciated! | | My pleasure! | - -Barry | | -----BEGIN PGP SIGNATURE----- | Version: GnuPG v1.4.7 (Darwin) | | iQCVAwUBRpIV/HEjvBPtnXfVAQLmdAP6A47uRwzcCBZ81Xao1OcoCjIPC+6c0sAd | wUtWPPzdkqp05sNAMQK3r22nH1d7ZRMVODhj01FcM/L+CGyRvH3tJtGT9WJOozIX | EeeehHPkZhS82nXWopPHE1y8J5DrgNrO0zujZZivOVufRN0ToqXSNGV8VYhn+jp6 | EuNq0FxAo+w= | =zdju | -----END PGP SIGNATURE----- | ------------------------------------------------------ | Mailman-Users mailing list | Mailman-Users@python.org | http://mail.python.org/mailman/listinfo/mailman-users | Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py | Searchable Archives: http://www.mail-archive.com/mailman- | users%40python.org/ | Unsubscribe: http://mail.python.org/mailman/options/mailman- | users/mkabot%40soarol.com | | Security Policy: http://www.python.org/cgi-bin/faqw- | mm.py?req=show&file=faq01.027.htp
On 7/9/07, Michael Kabot wrote:
I'd like to add a +1 for multiple domain support as well.
Barry's answered this one. All desires aside, the only real solutions we've found for this problem require some pretty massive architectural changes, at which point we're right back where we started from with Mailman 3.0.
Try the unsupported patches. If you're a programmer, make some code changes. If you can show us a suitable answer to this problem that doesn't require massive architectural changes, it will get serious consideration.
So far, that's the best answer that anyone can give.
-- Brad Knowles brad@shub-internet.org, Consultant & Author LinkedIn Profile: http://tinyurl.com/y8kpxu Slides from Invited Talks: http://tinyurl.com/tj6q4
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Brad,
Thanks. I didn't expect it to move from its current 3.0 slot, just adding a +1 for its importance.
I have multiple domains working by doing some "preprocessing" before Mailman. I tried the various patches and none worked well. My method makes sure I can use the most current Mailman release without have to modify any patches.
I concatenate the list name the user enters with their unique customer ID and then hand that guaranteed unique list name to mailman. I then add Qmail forwards within their domain for the list name to the list name w/ concatenation. It has solved my problem in the short term but has the disadvantage that users see the list concatenation name in email headers.
I would love to help, but afraid my Python experience is non existent. I fondly remember my Xerox PARC friends coding away in Python while I was using Perl, PHP, and C/C++ .....
Mike
| -----Original Message----- | From: Brad Knowles [mailto:brad@shub-internet.org] | Sent: Tuesday, July 10, 2007 12:16 PM | To: mkabot@soarol.com; mailman-users@python.org | Subject: Re: [Mailman-Users] Mailman roadmap | | On 7/9/07, Michael Kabot wrote: | | > I'd like to add a +1 for multiple domain support as well. | | Barry's answered this one. All desires aside, the only real | solutions we've found for this problem require some pretty massive | architectural changes, at which point we're right back where we | started from with Mailman 3.0. | | Try the unsupported patches. If you're a programmer, make some code | changes. If you can show us a suitable answer to this problem that | doesn't require massive architectural changes, it will get serious | consideration. | | So far, that's the best answer that anyone can give. | | -- | Brad Knowles brad@shub-internet.org, Consultant & Author | LinkedIn Profile: http://tinyurl.com/y8kpxu | Slides from Invited Talks: http://tinyurl.com/tj6q4 | | 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Michael Kabot writes:
I would love to help, but afraid my Python experience is non existent.
If you have coded in any language, well, Python is very readable. Try reading the Mailman code, starting with the email module. If you like, then help with the code. If it leaves you cold, continue to contribute other ways (feature specs, bug reports, doc author/editor, etc).
The main issue I personally find is just that Mailman is a fairly large application, depending on some fairly complex libraries, specifically the email module. You need to figure out what that module is about, and (for me) that's been the big hurdle. If you've got time to help, there's no big hurry at this point (Mailman isn't going to go away for at least another decade or so :-), take your time getting up to speed.
participants (7)
-
Barry Warsaw -
Brad Knowles -
David Lee -
Jeffrey Goldberg -
Krystal F. Zipfel -
Michael Kabot -
Stephen J. Turnbull