Search results for "Postorius" - Mailman-users

Re: Mailman, etc. upgrade woes and persistent bugs

by Abhilash Raj

I am trying to distill some information from this discussion to be used for the implementation in Postorius. I'll maybe reiterate a bit of what Steve was saying just to confirm I am on the same page. On Tue, Feb 16, 2021, at 7:23 AM, Stephen J. Turnbull wrote: > No answer required, I think I understand the situation pretty well > now. But if I'm missing something, I would very much appreciate > criticism. > > Andreas Barth writes: > > > Well, currently these are exclusive-states, I'd rather see them as > > or-able-states. > > Right, I understand that. I don't understand *why*. > > There are real costs to making them or-able. There are constraints: > 'enabled' shouldn't (mustn't?) be or-able with any 'disabled-by-foo' > state. Such invariants are finicky to code and tricky to maintain, > compared to a simple "mutually exclusive". > > I guess you want to allow the or of any subset of disabled states, but > presumably then they need to individually resettable in order for the > admin to clear their disable without overriding a subscriber's > preference or a bounce record. That set of controls is more complex, > and requires additional mental effort on the part of anyone using > them. If there are restrictions on which states can be or-ed, that's > more coding and maintenance cost. > > Then there's the question whether the subscriber can override the admin's > setting. If they can, why does the admin have this power in the first > place? > > > > > - "disabled by member" (could be set by an admin as well of course) > > > > > > Currently this is determined by whether the logged in user is the > > > subscriber or not. It's an interesting idea to allow it to be set by > > > an admin. Then we could have the semantics that the only transition > > > allowed from this state would be to enabled, so that admins would know > > > the user had intentionally disabled and know not to enable without > > > permission. > > > > Exactly. > > But if the admin should respect the DBS (disabled by subscriber) > setting, DBS|DBA (disabled by admin) is logically equivalent to DBS. > Are there use cases where the admin does not want to repect the > subscriber's choice, and enables it anyway? What are they? > > > Or while importing from another server, and there are people who > > have receiving mails disabled, this is the state that could be used > > for it. > > Why wouldn't they get the exact state from the original server? Or do > you mean from a non-Mailman server? > > > I expect that state to be the most-often used when setting a state > > manually. > > > > For "who set that", I would consider having some kind of history as > > useful (and displaying "last set by user / $person" to the admin but > > not the user). > > Why not to the subscriber? As I explain below, the subscriber at > least needs to be able to distinguish between DBA and DBB (disabled by > bounce). > > Keeping history of who is additional complexity, consumes a minor > amount of resources, and is insufficient to the purpose. Assuming > that there are reasons for admins to disable/enable other than as a > courtesy to a subscriber, that reason is presumably important. Not only > will the subscriber not know, but one admin may forget, and there may be > multiple admins.[1] > > I still don't see any reason for an admin to disable delivery other > than as a courtesy to the subscriber or to the bounce processor. > > > > > - "disabled for administrative reasons" (only by admin but user > > > > should be able to see it) > > > > > > I don't see why a user would need to see the difference. Unless > > > you're suggesting that the user would not be able to reenable without > > > asking the admin? What is the use case for this? > > > > I'm suggesting exactly that, yes. Why? Well, worked with user for too > > long. ;) > > > > E.g. consider that seeing archives works only for subscribers. And the > > subscriber in question complains about too many mails but still > > re-enables getting mails. This is basically "an admin has blocked you > > from more mails but not unsubscribed you". Might be an corner case, > > but still. Might also be too unimportant. > > This is possible. If it occurs less than once in a million years, > it's "too unimportant" to even think about.[2] Have you actually done > this, or know anybody who has? > > Is it really different from "at request of subscriber"? Practically, > the only difference I can see is if such a subscriber should be > prevented from overriding DBA. Are you suggesting that? > > > > > - "bounced" (user and admin could reset it but not set it) > > > > > > Reenable but not set "bounced" is the current situation. > > > > Except if someone sets the state to "disabled" and then undo this, the > > state is automatically cleared. > > This is possible, but it's not clear what harm would be done. In most > cases, bounces are intermittent and clear themselves up, in which case > this is the right thing. But if the subscriber bounces again, they'll > get disabled again, only cost is a slight waste of resources. > > Here's how I would assess the issues. In the descriptions below, I am > assuming that each state is the only "active" state. > > 1. DBS is probably a "vacation" or "post-only" setting. For that > reason it should be re-enabled only by the subscriber (or by an > admin at the request of the subscriber). > 2. DBB is a "warning" and a minor convenience to the email system > (slightly reducing traffic to mailboxes that are expected to fail, > and perhaps avoiding some reputational damage to the list). > Re-enabling much of the time causes no damage, as bounce disables > are typically due to things like out of disk space, and are likely > fixed by the time the subscription is reenabled. Most of the rest > will be zombie mailboxes, which will rarely be reenabled, will > quickly be redisabled by bounce, and at worst cause mild > inconvenience. Finally, events like a Mailman upgrade and the > April 2014 DMARC fiasco will be pretty evident, and the damage > there has already been done, reenabling actually fixes it > (although it may not be effective if the systemic problem hasn't > been resolved). > 3. DBA is interesting mostly to *subscribers*, who need to > distinguish DBA (which the subscriber can reenable freely) from > DBB (which warns the subscriber to get in touch with their > postmaster). It's comforting to subscribers who may be sure they > never disabled their subscription; otherwise, it's semantically > identical to DBS as far as I can see. > > Am I missing something? > > It seems to me that given 1-3, assuming a 4-state design: > > 0. It's never unreasonable to re-enable, except DBS. > 1. In the DBA state, changing to either DBS or DBB causes no > problems. (Changing to DBB is unlikely, since no mail is being > sent. However, it's possible, due to the race between Postorius > and mail in transit, and due to spam and other spoofing of the > list domain.) > 2. In either of the other two states, we should never change to DBA. > 3. In either of the other two states, if the other event occurs, you > would want the state to be DBS|DBB. I contend that if we > substitute DBS, little harm is done. If the subscriber reenables, it's > on them to fix the bounce problem if it reoccurs in any case. > Since the subscriber has deliberately set DBS, the admin should not > reenable without permission of the subscriber (I think we're mostly in > agreement on that). > > I think this 4-state design is much easier to design, validate, and > maintain than the 16-state design you propose. If you're really > worried about DBS|DBB, then we could have a 5-state design where > enabling from DBS|DBB generates a warning that there may still be a > bounce problem on the subscription. Instead, it could leave the > subscription in state DBB, but that seems to me to be obnoxious, since > there's little likelihood of harm from reenabling, and in many cases > the bounce problem will have resolved itself in the meantime. > So it seems like we have some sort of agreement that we need all the roles to be able to see all the 4 states. Roles here are basically Admin( i.e. list owner/moderator/site admin) and Subscriber. There is no access control to transition "from" any state but each value of non-enabled states is sort of a role's way to disable the delivery. Not all states are settable by all roles. 1. A subscriber can only transition from any to "enabled" or "by_user" state but can see if delivery was disabled "by_admin" or "by_bounces" as separate state in the Options page. 2. An admin can transition to "enabled", "by_user" and "by_moderator". They should use "by_user" when acting on behalf of the user and other when there are any administrative reason to disable delivery, whatever that may be. I expect "by_admin" to be used sparingly, and I don't see any use cases for it. 3. Mailman itself will use the "by_bounces" to disable delivery due to bounces. Is that an accurate description? -- thanks, Abhilash Raj (maxking)

4 years, 6 months

Templates branch for Mailman 3.1

by Barry Warsaw

Hello developers! There are three big features still in progress for Mailman 3.1, the templates branch, MySQL support, and unsubscription workflow. There is already a merge request for MySQL support and I'm hoping to merge that soon. Abhilash is also working on the unsubscription workflow feature but there's no MR for that yet. The templates feature is very nearly done, so I think now is a good time to ask for testing, feedback, and review. This is a generalization of the welcome_message_uri feature in MM3.0 where you could specify e.g. the welcome message as a URL to download and cache when necessary. This is important because Core doesn't know whether there is even a web ui (e.g. Postorius) involved, or where things like clickable links to unsubscribe would be. Sites also want to customize footers to include information like codes of conduct, etc. Now (or when this branch lands), you will be able to specify a URL to retrieve any template that Mailman uses internally, whether they are confirmation messages, bounce probes, welcome and goodbye messages, etc. These can be templates for administrators, users, and members. Because I'm hoping to get some reviews, I'll point you at the documentation for more details: https://gitlab.com/warsaw/mailman/blob/templates/src/mailman/rest/docs/temp… The branch did end up being much bigger and tentacled than I expected, but it's all hanging together pretty well now, and all the tests pass. There's still a small number of to-dos, but some of them will get punted, and the others won't have a major effect on the overall use and visibility of the feature. https://gitlab.com/warsaw/mailman/blob/templates/TODO.rst Note also that if you interact with the REST API v3.0, nothing changes externally, but the old IMailingList attributes are mapped onto the new templates mechanism. API v3.1 is where you see all the actual new feature end-points exposed. Of course, any MM2 list converted to MM3.1 will use the new templates stuff too. Feedback very much welcome, either here or on the MR: https://gitlab.com/mailman/mailman/merge_requests/170 I'd like to land this some time in the next week or so. Then I'll work on the other two big branches and start to release some betas. Cheers, -Barry

9 years, 2 months

Re: Problems after update to mailman 3.3.7

by Danil Smirnov

Hi Guillermo, We've faced the same issue and already reported it: https://gitlab.com/mailman/mailman/-/issues/1044 I would not recommend anyone using MySQL/MariaDB database engine upgrade to the latest version yet. With my best regards, Danil Smirnov Mailman3.com On Tue, Dec 6, 2022 at 4:32 PM Guillermo Hernandez (Oldno7) via Mailman-users <mailman-users(a)mailman3.org> wrote: > I've getting the most strange behaviour after update to last releases. > In one of my mailman3 servers, the messages doesnt reach for some lists > (the five last ones) > > the update have not showed any error but in the var/data for the lmtp > and vmap postfix files mailman does not create aliases for that last 5 > lists. Any message addressed to them is returned with a "no such user" > error. > > If I create a new list the system or restart mailman runners it shows > this error: > > Generating MTA alias maps > /usr/local/lib/python3.9/site-packages/pymysql/connections.py:799: > UserWarning: Previous unbuffered result was left incomplete > warnings.warn("Previous unbuffered result was left incomplete") > > I did a CHECK TABLE on mailinglists table but all seems ok. > > I tried reinstalling PyMySQL, but has no effect. (well, I tried > reinstalling all) > > It seems to me that something is preventing creation of that aliases, an > then the that last five lists are unreachable. > > I have no clue of what to do now and I'm driving crazy. > > Some direction to look for will be much apreciated. > > Thanks in advance. > > P.S.: I can access via postorius/hyperkitty to the archives of the lists > that are unreacheable. > > > -- > > ___________________________________________ > Mailman's content filtering has removed the > following MIME parts from this message. > > Content-Type: image/png > Name: firma-GHP-emails.png > > Replaced multipart/alternative part with first alternative. > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > Archived at: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to danil(a)smirnov.la >

2 years, 9 months

Re: Mailman, etc. upgrade woes and persistent bugs

by Stephen J. Turnbull

Andreas Barth writes: > * Stephen J. Turnbull (turnbull.stephen.fw(a)u.tsukuba.ac.jp) [210217 09:54]: > > Right. So what you mean is "ok, we have group permissions, and maybe > > someday there will be a case for ACLs down to arbitrary subsets of the > > user population," but you don't have a concrete use case for arbitrary > > ACLs at the moment. > I definitly have a usecase for that, but: currently other priorities :) > (I had to do an ad-hoc takeover of lots of infrastructure in my spare > time within an volunteer organisation including mailing lists, so > getting wishlist itmes done is not my top priority at the moment.) > > Just from the top of my head, for example I want to differentiate > between private, member and public lists. So if a member logs in, they > see more lists than a non-member. This is currently not possible, not > too big a deal (all member lists are currently configured as private) > but of course would be nice. Also archiv access should be aligned with > these permissions. This would not be worth doing with generic ACLs from Postorius, unless the list had (many) fewer than 100 users. What I'd end up doing (and I bet you would too) is write a 15-line mailmancli script that extracted membership information and then created the ACLs. But you'd still have to modify the Django templates, I suspect, and perhaps database schema. Essentially the same 15 lines could be put into Mailman itself without ACLs, and checking ACL membership is not going to be much, if at all, faster than checking list membership. > Of course the appropriate split between private changes and public > changes is also something which might need some discussions. Not sure what you mean by private and public here, but if you mean which changes we should maintain and which changes you should maintain locally, I haven't seen anything in this thread that we wouldn't want to offer all Mailman 3 users. From Abhilash's and Mark's posts, I believe they feel that way too. It's just a question of whether a very general implementation is needed/worthwhile. Steve

4 years, 6 months

Re: Emergency moderation and clearing out a lot of held messages

by Abhilash Raj

On 12/14/22 03:31, Mark Sapiro wrote: > On 12/13/22 10:38, Dan Caballero wrote: >> Hi Mark, >> >> I ran the commands and it took about 35 seconds for the loop to run. >> >> Here's the result. >> >>>>> count >> 4168 > > > So that's at least part of the issue. How does 35 seconds compare to the > length of time to process one moderated message through Postorius? > Probably should've read more of the thread before previous reply ;-) So, the issue _could_ be due to latency to the remote database vs local database that we have on m.p.o. Mailman3 is not very efficient when it comes to total no. of database queries done per operation, which is something I have been (very slowly) tracking and fixing on a case-by-case basis. So, for example, handling 1 held message in m.p.o made 1.1k postgres database calls in total and even though they were each only few hundred micro-seconds each, the total added up to roughly ~2sec avg response time on the handle message API endpoint. If you handle more than 1, it scales linearly. My suspicion is that in your case Dan, due to a remote instance, the latency per call is higher (maybe in the order of few or 10s of milliseconds is my guess?) and then depending on the total no. of entries you have in pendings and pendedkeyvalue tables (with some filters, not _all_ entries), it adds up to a high value. The no. of database calls here is of order n^2, where n is the entries in pendings of type "held message" and "data" and their respective linked relationships in pendedkeyvalue table. My MR makes it such that we don't need to scan all entries of "type"="data", so that part will become constant time. And the pending of type "held message" will be limited to no. of held messages in a single MailingList(compared to all mailing lists like today), so it will help depending on the distribution of held messages in various lists. I am also exploring ways to make that 2nd query also constant time. -- thanks, Abhilash Raj (maxking)

2 years, 9 months

Re: MM3 Postfix FROM header issue

by eboltz＠lhtservices.com

Mark, Thanks for the assistance thus far. When I create a new Domain within Postorius. If I set the Mail Host to 'example.com' and the Alias Domain to 'lists.example.com', create a new list such as 'staff_test', it'll default to the 'example.com' domain (which is the real domain). Then when I subscribe, I'll get an email from 'staff_test(a)example.com', when I want it to be from 'staff_test(a)lists.example.com' instead, also if I reply back to the 'staff_test(a)example.com' then I"ll get a bounce-back that it doesn't exist, but if I send to 'staff_test(a)lists.example.com' it'll go to the newly created list. I'd like all defaults to be '@lists.example.com', if that makes sense. Here are the settings of my postfix_lmtp and postfix_vmap # AUTOMATICALLY GENERATED BY MAILMAN ON 2023-12-17 20:05:34 # # This file is generated by Mailman, and is kept in sync with the binary hash # file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what you're # doing, and can keep the two files properly in sync. If you screw it up, # you're on your own. # Aliases which are visible only in the @lists.example.com domain. staff_test(a)lists.example.com lmtp:[127.0.0.1]:8024 staff_test-bounces(a)lists.example.com lmtp:[127.0.0.1]:8024 staff_test-confirm(a)lists.example.com lmtp:[127.0.0.1]:8024 staff_test-join(a)lists.example.com lmtp:[127.0.0.1]:8024 staff_test-leave(a)lists.example.com lmtp:[127.0.0.1]:8024 staff_test-owner(a)lists.example.com lmtp:[127.0.0.1]:8024 staff_test-request(a)lists.example.com lmtp:[127.0.0.1]:8024 staff_test-subscribe(a)lists.example.com lmtp:[127.0.0.1]:8024 staff_test-unsubscribe(a)lists.example.com lmtp:[127.0.0.1]:8024 # AUTOMATICALLY GENERATED BY MAILMAN ON 2023-12-17 20:05:34 # # This file is generated by Mailman, and is kept in sync with the binary hash # file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what you're # doing, and can keep the two files properly in sync. If you screw it up, # you're on your own. # Virtual mappings for the @example.com domain. staff_test(a)example.com staff_test(a)lists.example.com staff_test-bounces(a)example.com staff_test-bounces(a)lists.example.com staff_test-confirm(a)example.com staff_test-confirm(a)lists.example.com staff_test-join(a)example.com staff_test-join(a)lists.example.com staff_test-leave(a)example.com staff_test-leave(a)lists.example.com staff_test-owner(a)example.com staff_test-owner(a)lists.example.com staff_test-request(a)example.com staff_test-request(a)lists.example.com staff_test-subscribe(a)example.com staff_test-subscribe(a)lists.example.com staff_test-unsubscribe(a)example.com staff_test-unsubscribe(a)lists.example.com

1 year, 9 months

Re: Mailman3 in dockers on EC2 - running out of memory and puking ev.ry.where.

by Abhilash Raj

On Tue, Apr 9, 2019, at 2:34 PM, roger.hislop(a)is.co.za wrote: > Hi all -- really need some help. I'm tech literate, but definitely not > a sysadmin or dev. > > I'm following the tutorial at "Olay's Farmland" at > https://www.olay.xyz/2018/01/01/deploy-mailman-3-on-aws-using-docker/ > which seems to be a clone of the same content here > https://xiaoxing.us/2018/01/01/deploy-mailman-3-on-aws-using-docker/ The right place to get help regarding these guides would be the author of the posts, which AFAIK, have no affiliation with Mailman Core Team. On a (very) quick glance, it seems fine. > Easy enough to get most of the way ... set up EC2 instance, configure > SES and add DNS settings with DKIM etc. Set up Postfix, test it. All > working groovy. > > I run through the how to all the way through setting up the containers > and firing it up. This is where things start to get funky. > > Once the docker-compose is run, I run "curl > http://172.19.199.3:8000/postorius/lists/" to test. First time it said > it couldn't connect to database. So I nuked and restarted from scratch. > Second time it said the same thing... was reading around the place and > tried again, and then reran that curl and it worked -- gave me html > from a page. But the VM started running slowly --taking forever to > follow keypresses. > > Eventually became unresponsive. So I rebooted the machine via AWS > console, and docker ps showed only the postgres db running. > docker-compose ps shows > Name Command State > Ports > ------------------------------------------------------------------------------------------ > docker-mailman_database_1 docker-entrypoint.sh postgres Up > 5432/tcp > mailman-core docker-entrypoint.sh maste ... Exit 255 > 8001/tcp, 8024/tcp > mailman-web docker-entrypoint.sh uwsgi ... Exit 255 > 8000/tcp, 8080/tcp > > So rebuilt the container -- same thing. It looks and feels like its > running out of memory. > > I used the compose file from > https://gist.githubusercontent.com/Yexiaoxing/833bfcc5d3e4e0c06a8b7f0bac7c4… (with appropriate edits). How much memory do yo have in your VM? Have you tried using a bigger VM? thanks Abhilash

6 years, 5 months

Re: About to Install MM3 -- Seeking clarification

by Onyeibo Oku

On Wed, 12 Oct 2022 17:52:47 -0700 Mark Sapiro <mark(a)msapiro.net> wrote: Thanks Eggert and Sapiro. > > As Eggert suggests, see > https://docs.mailman3.org/en/latest/install/virtualenv.html and > follow that. I already started out on the above route. Its an adaptation because I am running Fedora. I had no problem with system-wide installations via dnf package management. However, some parts of the documentation does not add up. > You don't need to download the source from GitLab. > Following that doc will get the latest releases from PyPI via pip. > Those are still somewhat out of date - we really should make new > releases - so if you want the latest from GitLab, there are a couple > of ways to do it. Perhaps the easiest is to just run the various `pip > install` commands as documented and then upgrade Mailman core in your > venv with ``` > pip install --upgrade git+https://gitlab.com/mailman/mailman@master > ``` > and update the various mailman web packages with > ``` > pip install --upgrade git+https://gitlab.com/mailman/xxx@master > ``` > where xxx is mailman-web, mailman-hyperkitty, django-mailman3, > postorius, hyperkitty. I.e., run it 5 times, once for each value of > xxx. > I will come to this eventually (assuming that does not break things later). I aim to get it all working with regular pip packages first. I have installed mailman core already. Fedora expects mailman files to reside at /usr/lib/mailman. It appears to ship with a mailman unix user. I adapted to those system defaults. Now I observe that "su - mailman" gives me the proper prompt but .bashrc doesn't kick in. I still have to manually change to the virtual environment despite setting the automatic change in .bashrc. However, "su mailman" runs .bashrc but the prompt says "bash X.XX $". Is this normal? Subsequent parts of the doc show the path "/opt/mailman/mm/var/*" which should correspond to "/usr/lib/mailman/mm/var/*" on my instance. However, I don't see any instructions on how to get the "/mm" folder and the associated sub-folders. I just have "/usr/lib/mailman" I am lost "pip list" within the venv environment confirms that I have "mailman 3.3.5". What am I missing? Regards Onyeibo

2 years, 11 months

hosted signup is producing unexpected results

by tokyoprogressive＠mac.com

In my test of the two forms of signup, I am getting these unexpected results. Is it my settings or is something weird within the program itself? 1) https://list.tokyoprogressive.org/postorius/lists/discuss.list.tokyoprogres… 2) Choose "You can also subscribe without creating an account. If you wish to do so, please use the form below" 3) Then I have to approve it. They get "Welcome to the "Discuss" mailing list! To post to this list, send your email to: discuss(a)list.tokyoprogressive.org 4) But I have to approve it.I assume this is because they do not yet have a real account. And they should be listed as a NON MEMBER? 5) But even when they sign up here: https://list.tokyoprogressive.org/accounts/signup/?next=%2Fpostorius%2Flist… they get an email from my provider (NOT MY LIST????) as follows: "Hello from mailman3.emwd.com! You're receiving this e-mail because user iCloud has given yours as an e-mail address to connect their account. To confirm this is correct, go to https://list.tokyoprogressive.org/accounts/confirm-email/MTE3:1iA44k:E7w7xh… Thank you from mailman3.emwd.com! mailman3.emwd.com" 6) And this is where it gets weird. If they send from their email program and get the welcome (Welcome to the "Discuss" mailing list! To post to this list, send your email to: discuss(a)list.tokyoprogressive.org You can unsubscribe or make adjustments to your options via email by sending a message to....... I then get a notice: "Your mail to 'discuss(a)list.tokyoprogressive.org' with the subject test notice Is being held until the list moderator can review it for approval. The message is being held because: The message is not from a list member" 7) While if they send FROM THE interface it goes through. 8) What I am confused about. Signing up for an account should make them a member, right? Subscribing should make them a non member, no? But here it seems that both make them a non member. And worse, someone with an account sending from the Interface has their message get through while the same person sending from an email program has me get a notice that a non member is trying to post. Before I can move my actual members over from another mailing list provider, I want to make sure what works and what doesn't. Thanks. paul!!!

6 years

Re: [MM3-users]Re: [Mailman-Users] Mailman3 administration

by Barry Warsaw

On Jun 20, 2016, at 10:47 PM, Bill wrote: >And it leads me to think about timelines. > >I'm aware that the freeze for Debian 9 (Stretch) is scheduled for the end of >this year, and that we can expect it to be released sometime in >mid-2017. (Don't quote me on that though ;) And I'm not sure about Centos, I >didn't see a Mailman 3.0 package there or in Fedora. We have a Debian maintainer who did some work on packaging, but got stuck on a few issues. I think one of the biggest problems is also something that HK/Postorius is grappling with right now - the eminent demise of persona.org. Work is being done to switch over to django-social-auth, and that's a blocker for a full 3.1 suite release. For the core, the last big missing thing is the unsubscription workflow (see GL#213). I'll be looking at that, trying to adapt or finish Abhilash's work there. >But is there any chance that a Mailman 3.0 or 3.1 package is going to make it >into current release cycles? I'd like for it to happen; we'll have to see. >But we're in the evaluation/design phase of this project and from the >providers point of view it would be helpful to know if they should wait a few >months for Mailman 3.0/3.1 or just go ahead now with 2.1.x and upgrade to 3.1 >at some point down the road. While their list admins are experienced, they >are new to Mailman and the fewer burps the better. Although they may very >well take a run at 3.0 now and see how things work out. We just need some >sort of timeline to consider. I still think we can get a 3.1 release out by year's end, if not sooner. As I say, we have just a couple of blockers left, though they may or may not be small. I'd say, don't try to deploy 3.0, but either go with the git heads, or wait for hopefully some beta releases of 3.1 coming soon. I am seriously considering not releasing a 3.0.4 and just EOL'ing 3.0.x once 3.1 is released. It should be a smooth upgrade if you already have 3.0 deployed. Cheers, -Barry

9 years, 1 month

Mailman-users search results for query "Postorius"